RAND 


NATIONAL  DEFENSE 
RESEARCH  INSTITUTE 


CHILDREN  AND  FAMILIES 

EDUCATION  AND  THE  ARTS 

ENERGY  AND  ENVIRONMENT 

HEALTH  AND  HEALTH  CARE 

INFRASTRUCTURE  AND 
TRANSPORTATION 

INTERNATIONAL  AFFAIRS 

LAW  AND  BUSINESS 

NATIONAL  SECURITY 

POPULATION  AND  AGING 

PUBLIC  SAFETY 

SCIENCE  AND  TECHNOLOGY 

TERRORISM  AND 
HOMELAND  SECURITY 


The  RAND  Corporation  is  a  nonprofit  institution  that 
helps  improve  policy  and  decisionmaking  through 
research  and  analysis. 

This  electronic  document  was  made  available  from 
www.rand.org  as  a  public  service  of  the  RAND 
Corporation. 


Skip  all  front  matter:  Tump  to  Page  1  ▼ 


Support  RAND 

Purchase  this  document 
Browse  Reports  &  Bookstore 

Make  a  charitable  contribution 


For  More  Information 

Visit  RAND  at  www.rand.org 

Explore  the  RAND  National  Defense 
Research  Institute 

View  document  details 


Limited  Electronic  Distribution  Rights 

This  document  and  trademark(s)  contained  herein  are  protected  by  law  as  indicated 
in  a  notice  appearing  later  in  this  work.  This  electronic  representation  of  RAND 
intellectual  property  is  provided  for  non-commercial  use  only.  Unauthorized  posting 
of  RAND  electronic  documents  to  a  non-RAND  website  is  prohibited.  RAND 
electronic  documents  are  protected  under  copyright  law.  Permission  is  required 
from  RAND  to  reproduce,  or  reuse  in  another  form,  any  of  our  research  documents 
for  commercial  use.  For  information  on  reprint  and  linking  permissions,  please  see 
RAND  Permissions. 


This  report  is  part  of  the  RAND  Corporation  research  report  series. 
RAND  reports  present  research  findings  and  objective  analysis  that 
address  the  challenges  facing  the  public  and  private  sectors.  All  RAND 
reports  undergo  rigorous  peer  review  to  ensure  high  standards  for  re¬ 
search  quality  and  objectivity. 


data  flood 


Helping  the  Navy  Address  the  Rising 
Tide  of  Sensor  Information 


Isaac  R.  Porche  III  •  Bradley  Wilson 
Erin-Elizabeth  Johnson 
Shane  Tierney  •  Evan  Saltzman 


RAND 

CORPORATION 


RAND 


NATIONAL  DEFENSE  RESEARCH  INSTITUTE 


data_flood 

Helping  the  Navy  Address  the  Rising 
Tide  of  Sensor  Information 


Isaac  R.  Porche  III  •  Bradley  Wilson 
Erin-Elizabeth  Johnson 
Shane  Tierney  •  Evan  Saltzman 


Prepared  for  the  Office  of  the  United  States  Navy 

Approved  for  public  release;  distribution  unlimited 


This  research  was  sponsored  by  the  Department  of  the  Navy  and  conducted 
within  the  Acquisition  and  Technology  Policy  Center  of  the  RAND  National 
Defense  Research  Institute,  a  federally  funded  research  and  development 
center  sponsored  by  the  Office  of  the  Secretary  of  Defense,  the  Joint  Staff, 
the  Unified  Combatant  Commands,  the  Navy,  the  Marine  Corps,  the  defense 
agencies,  and  the  defense  Intelligence  Community. 


Library  of  Congress  Cataloging-in-Publication  Data 
ISBN;  978-0-8330-8429-3 


The  RAND  Corporation  is  a  nonprofit  institution  that  helps  improve  policy 
and  decisionmaking  through  research  and  analysis.  RAND’s  publications  do 
not  necessarily  reflect  the  opinions  of  its  research  clients  and  sponsors. 

Support  RAND  — make  a  tax-deductible  charitable  contribution  at 
WWW.  rand .  org/  giving/  contribute .  ht  ml 

RAND®  is  a  registered  trademark 

Cover  by  Pete  Soriano 

©  Copyright  2014  RAND  Corporation 

This  document  and  trademark(s)  contained  herein  are  protected  by  law.  This 
representation  of  RAND  intellectual  property  is  provided  for  noncommercial  use  only. 
Unauthorized  posting  of  RAND  documents  to  a  non-RAND  website  is  prohibited. 
RAND  documents  are  protected  under  copyright  law.  Permission  is  given  to  duplicate 
this  document  for  personal  use  only,  as  long  as  it  is  unaltered  and  complete.  Permission 
is  required  from  RAND  to  reproduce,  or  reuse  in  another  form,  any  of  our  research 
documents  for  commercial  use.  For  information  on  reprint  and  linking  permissions, 
please  see  the  RAND  permissions  page  (www.rand.org/pubs/permissions.html). 

RAND  OFFICES 

SANTA  MONICA,  CA  •  WASHINGTON,  DC 
PITTSBURGH,  PA  •  NEW  ORLEANS,  LA  •  JACKSON,  MS  •  BOSTON,  MA 
CAMBRIDGE,  UK  •  BRUSSELS,  BE 
www.rand.org 


Preface 


The  title  of  this  report  was  inspired  by  the  comments  of  former  U.S. 
Air  Force  intelligence  lead  Lt  Gen  David  A.  Deptula  (ret.),  who  fore¬ 
cast  in  2012  that  his  service  would  soon  be  “swimming  in  sensors  and 
drowning  in  data”  from  unmanned  air  vehicles.^  This  report  provides 
a  summary  of  results  from  two  studies  conducted  by  the  RAND  Cor¬ 
poration  for  the  U.S.  Navy.  The  overarching  concern  in  both  studies 
was  the  “flood”  of  data  coming  from  the  intelligence,  surveillance,  and 
reconnaissance  (ISR)  systems  that  Navy  intelligence  analysts  and  com¬ 
manders  rely  on  for  situational  awareness.  The  first  study  identified 
the  year  in  which  the  effects  of  this  “flood”  would  first  be  felt  (2016).^ 
The  second  constituted  the  analysis  of  alternatives  for  the  Distributed 
Common  Ground  System-Navy  Increment  2,  a  system  intended  to 
help  the  Navy  address  the  influx  of  data.  This  report  describes  the 
Navy’s  “big  data”  challenge  and  outlines  potential  solutions  involv¬ 
ing  changes  along  four  dimensions:  people,  tools  and  technology,  data 
and  data  architecture,  and  demand  and  demand  management.  We  also 
discuss  broader  issues  related  to  the  challenges  and  opportunities  pre- 


^  Stew  Magnuson,  “Military  ‘Swimming  in  Sensors  and  Drowning  in  Data,”’  National 
Defense  Magazine,  January  2010. 

^  Ed  Brady,  Jim  Bexfield,  Jim  Hildegrand,  and  John  Orem,  “Analytical  Approaches  to  Air¬ 
borne  ISR  MORS  Workshop:  A  Summary  of  Results  from  the  Perspective  of  the  Synthe¬ 
sis  and  Integration  Group,”  presentation  at  the  National  Defense  University,  Washington, 
D.C.,  June  25,  2012;  Isaac  R.  Porche  III,  Bradley  Wilson,  Shane  Tierney,  Ray  Koym,  James 
Dryden,  Evan  Saltzman,  Roland  J.  Yardley,  John  M.  Yurchak,  Stephanie  Young,  Endy  M. 
Daehner,  Megan  McKernan,  and  Kate  Giglio,  The  DCGS-Navy  Increment  2  Analysis  of  Alter¬ 
natives:  Options  for  Meeting  the  TCPED  Challenges  and  Opportunities,  Santa  Monica,  Galif.: 
RAND  Gorporation,  2013. 
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sented  by  ISR  data.  This  report  should  be  of  interest  to  the  Navy  and 
other  services,  agencies,  and  organizations  that  rely  on  ISR  data. 

This  report  is,  in  essence,  an  executive  summary  of  several  longer, 
more-detailed  reports,  including  a  peer-reviewed  briefing  presented  at  a 
Military  Operations  Research  Society  Airborne  ISR  workshop.^ 

This  research  was  sponsored  by  the  Department  of  the  Navy  and 
conducted  within  the  Acquisition  and  Technology  Policy  Center  of 
the  RAND  National  Defense  Research  Institute,  a  federally  funded 
research  and  development  center  sponsored  by  the  Office  of  the  Secre¬ 
tary  of  Defense,  the  Joint  Staff,  the  Unified  Combatant  Commands, 
the  Navy,  the  Marine  Corps,  the  defense  agencies,  and  the  defense 
Intelligence  Community.  Questions  and  comments  about  this  research 
are  welcome  and  should  be  directed  to  the  project  leader,  Isaac  Porche, 
at  Isaac_Porche@rand.org,  or  to  the  center  director,  Cynthia  Cook 
(Cynthia_Cook@rand.org) 

For  more  information  on  the  RAND  Acquisition  and  Technol¬ 
ogy  Policy  Center,  see  http://www.rand.org/nsrd/ndri/centers/atp 


^  A  summary  of  proceedings  for  the  entire  workshop  is  at  Brady  et  ah,  2012. 
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Summary 


U.S.  Navy  intelligence,  surveillance,  and  reconnaissance  (ISR)  func¬ 
tions  have  become  critical  to  U.S.  national  security  over  the  last  two 
decades.^  Within  the  Navy,  there  is  a  growing  demand  for  ISR  data 
from  drones  and  other  sources  that  provide  situational  awareness, 
which  helps  Navy  vessels  avoid  collisions,  pinpoint  targets,  and  per¬ 
form  a  host  of  other  mission-critical  tasks. 

The  amount  of  data  generated  by  ISR  systems  has,  however, 
become  overwhelming.  All  of  the  data  collected  by  the  Navy — and 
available  from  other  sources,  both  government  and  commercial — are 
potentially  useful,  but  processing  them  and  deriving  useful  knowledge 
from  them  are  severely  taxing  the  analytical  capabilities  of  the  Navy’s 
humans  and  networks.  As  the  Navy  acquires  and  fields  new  and  addi¬ 
tional  sensors  for  collecting  data,  this  “big  data”  challenge  will  con¬ 
tinue  to  grow.  Indeed,  if  the  Navy  continues  to  field  sensors  as  planned 
but  does  not  change  the  way  it  processes,  exploits,  and  disseminates 
information,  it  will  reach  an  ISR  “tipping  point” — the  point  at  which 
intelligence  analysts  are  no  longer  able  to  complete  a  minimum  number 
of  exploitation  tasks  within  given  time  constraints — as  soon  as  2016.^ 

Today,  as  little  as  5  percent  of  the  data  collected  by  ISR  platforms 
actually  reach  the  Navy  analysts  who  need  to  see  them.  In  the  case  of 


^  The  Joint  Chiefs  of  Staff  defines  ISR  as  the  “synchronized,  integrated  planning  and 
operation  of  sensors,  processing,  exploitation  and  dissemination  systems  in  direct  support 
of  current  and  future  operations.”  It  also  states  that  this  is  “an  integrated  intelligence  and 
operations  function”  (Joint  Chiefs  of  Staff,  Department  of  Defense  Dictionary  of  Military  and 
Associated  Terms,  November  8,  2010,  as  amended  through  July  15,  2012). 

^  Brady  et  ah,  2012;  Porche  et  ah,  2013. 
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analysts  working  afloat  on  ships,  a  large  part  of  the  problem  is  attrib¬ 
utable  to  extremely  slow  download  times  caused  by  bandwidth  and 
connectivity  limitations.  Analysts  face  other  challenges  to  the  timely 
consumption  of  data,  including  having  to  share  access  to  communica¬ 
tions  pipelines  with  other  organizations  and  having  to  download  mul¬ 
tiple  pieces  of  large  data  (such  as  high-resolution  images)  to  find  exactly 
what  they  need.  Most  of  the  time,  analysts  do  not  have  the  luxury  of 
receiving  the  “right”  data  in  a  timely  fashion. 

Today  s  analysts  also  face  a  wide  variety  of  data  streaming  in  from 
different  platforms  and  sensors — data  they  must  integrate  (or  fuse)  to 
ensure  accurate,  comprehensive  situational  awareness.  Their  worksta¬ 
tions  are  cluttered  with  different  software  applications  and  monitors 
that  rely  on  data  that  often  reside  in  separate  databases  or  on  sepa¬ 
rate  networks.  These  factors  degrade  analysts’  ability  to  integrate  and 
fuse  multiple  intelligence  types  accurately,  quickly,  and  thoroughly. 
Common  wisdom  among  analysts  is  that  they  spend  80  percent  of 
their  time  looking^r  the  right  data  and  only  20  percent  of  their  time 
looking  at  the  right  data. 

One  option  for  ensuring  that  Navy  analysts  are  better  able  to  cope 
with  big  data  is  dynamically  managing  their  workloads.  Today,  the 
Navy’s  intelligence  specialists  are,  for  the  most  part,  working  on  “local 
tasks,”  since  the  allocation  of  tasks  tends  to  be  based  on  which  ana¬ 
lysts  are  nearby  or  statically  assigned,  rather  than  on  who  is  available 
to  accept  new  tasking.  The  main  disadvantage  of  today’s  fixed,  geo¬ 
graphically  based  tasking  arrangements  is  that  intelligence  specialists 
in  one  location  can  become  quickly  overwhelmed  with  tasks  that  need 
not  necessarily  be  assigned  to  them  but  that,  because  of  the  local  task¬ 
ing  model,  come  their  way  by  default.  Through  modeling  and  simula¬ 
tion,  we  determined  that  tasking  models  that  operate  at  the  regional 
or  global  level — models  in  which  tasks  are  automatically  shared  based 
on  who  is  available  to  accept  new  tasking — outperform  today’s  local 
model  in  terms  of  the  productivity  of  imagery  analysts. 

Changes  to  how  workloads  are  managed  are  not,  on  their  own,  a 
sufficient  long-term  solution  to  the  Navy’s  big  data  challenge,  however. 
To  be  complete,  a  solution  must  involve  changes  along  all  of  the  fol¬ 
lowing  four  dimensions: 
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•  people 

•  tools  and  technology 

•  data  and  data  architectures 

•  demand  and  demand  management.^ 

In  conducting  an  analysis  of  alternatives  for  the  Distributed 
Common  Ground  System-Navy  Increment  2  (a  system  intended  to 
help  the  Navy  address  the  influx  of  data),  we  developed  three  potential 
alternatives.  Relative  to  the  baseline,  each  increases  the  Navy’s  ability 
to  better  manage  and  use  the  rising  flood  of  ISR  data.  All  three  alter¬ 
natives  assume  that  the  Navy  begins  to  dynamically  manage  analysts 
workloads  and  that  sensors  are  cued  smartly.^  S.l  describes  the  base¬ 
line  and  each  of  the  three  alternatives. 

Modeling  and  simulation  reveal  that  all  three  alternatives  out¬ 
perform  the  baseline  when  it  comes  to  finding  the  greatest  number  of 
targets  in  the  smallest  amount  of  time — a  performance  metric  that 
indicates  how  quickly  a  commander  can  be  made  aware  of  the  targets 
around  his  or  her  area  of  command.  This  is  especially  true  when  ana¬ 
lysts  must  analyze  data  of  multiple  intelligence  types.  In  such  cases, 
alternatives  2  and  3  vastly  outperform  both  the  baseline  and  alterna¬ 
tive  1. 

We  recommend  that  the  Navy  pursue  alternative  3  (cloud) — a 
strategy  similar  to  those  adopted  by  Google,  the  Intelligence  Commu¬ 
nity  (IC),  and  other  large  organizations  grappling  with  big  data’s  chal¬ 
lenges  and  opportunities.  Specifically,  we  recommend  that  the  Navy 
adopt  the  IC’s  cloud  approach,  designing  its  next  generation  of  ISR 
tools  and  systems  to  work  with  the  National  Security  Agency’s  dis¬ 
tributed  cloud  concept  (i.e.,  the  Intelligence  Community  Government 
Cloud).  This  information  architecture  should  be  sufficient  to  meet  the 


^  The  corresponding  workflow  processes  are  vital  as  well.  See  Isaac  R.  Porche  III,  Evan 
Saltzman,  Roland  Yardley,  and  Gordon  Lee,  “MAXINT,”  presentation  at  the  Military  Oper¬ 
ations  Research  Workshop  on  Analytic  Approaches  to  Airborne  ISR,  National  Defense  Uni¬ 
versity,  Ft.  McNair,  Washington,  D.C.,  April  2012;  and  Porche  et  ah,  2013. 

^  This  means  that  sensors  are  only  turned  on  as  needed  rather  than  being  kept  on  continu¬ 
ously.  Sensors  cued  to  the  target  send  more-relevant  data  and  thus  lower  burdens  on  band¬ 
width  and  on  analysts’  cognitive  reserves. 


Figure  S.1 

The  Baseline  and  the  Three  Alternatives 


Description  People 


Tools  and  Data  and  Demand  and 

Technology  Data  Architecture  Demand  Management 


Baseline 


This  baseline 
relies  on  current 
plans. 


There  are  fewer  afloat  There  is  no  change, 
analysts.  (DECREASE)  (NO  CHANGE) 


There  is  no  change  in  the  There  is  no  change  in 
approach  to  analyzing  data.  managing  personnel 
(NO  CHANGE)  workflows  or  in  managing 

demand  for  data. 

(NO  CHANGE) 


Alternative!:  This  alternative 

Applications  adds  applications. 


There  are  fewer  afloat 
analysts,  but  there  is 
increased  reliance  on 
reachback  personnel. 

(REARRANGEMENT) 


Alternative  2: 
Consolidation 


BBS 

0  0 


This  alternative 
leverages  an  SOA 
(e.g.,  the  CANES 
program  of 
record). 


There  are  fewer  afloat 
analysts,  but  there  is 
increased  reliance  on 
reachback  personnel. 

(REARRANGEMENT) 


The  Navy  adds 
applications,  including 
workflow-automation 
tools. 

(INCREASE 

APPLICATIONS) 


There  is  no  change  in  the 
approach  to  analyzing  data. 

(NO  CHANGE) 


The  Navy  manages  personnel 
workloads  dynamically.  Sensors 
are  cued  smartly.  ^ ^ 


The  Navy  adds  more- 
interoperable  services 
to  enhance  workflow 
automation. 

(INCREASE 

SERVICES) 


The  Navy  copies  the  Army's 
approach  of  depending  on 
an  information  clearinghouse 
(aka  "fusion  brain").  - n 


The  Navy  manages  personnel 
workloads  dynamically.  Sensors 
are  cued  smartly.  ^ ^ 


Alternative  3:  This  alternative 


There  are  fewer  afloat 
analysts,  but  there  is 
increased  reliance  on 
reachback  personnel. 

(REARRANGEMENT) 


The  Navy  adds  more 
services  and  widgets. 

(INCREASE 

SERVICES) 


The  Navy  relies  on  the 
IC's  virtual  data  analytic 
cloud. 


The  Navy  manages  personnel 
workloads  dynamically.  Sensors 
are  cued  smartly.  ^ ^ 


t  tt 


SOURCES:  Screen  images  by  Eugene  Sergeev  and  Marcin  Gardychowski  via  Fotolia. 

NOTES:  CANES  =  Consolidated  Afloat  Networks  and  Enterprise  Services;  ICGovCIoud  =  Intelligence  Community 
Government  Cloud;  SOA  =  service-oriented  architecture. 
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growing  volumes  of  data  that  will  need  to  be  harvested  and  thus  enable 
viable  tasking,  collection,  processing,  exploitation,  and  dissemination 
(TCPED)  operations  in  the  future.  Integrating  and  leveraging  an  IC- 
developed  distributed  cloud  architecture  will  enable  some  reachback 
for  analysis  and  help  analysts  cope  with  the  increasing  variety  and 
volume  of  data,  thereby  improving  their  ability  to  help  commanders 
make  better  decisions. 
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JEMA 
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SOA 

service-oriented  architecture 

STUAS 

Small  Tactical  Unmanned  Aircraft  System 

TCPED 

tasking,  collection,  processing,  exploitation,  and 
dissemination 
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Top  Secret/Sensitive  Compartmented  Information 

UAV 

unmanned  aerial  vehicle 
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Unmanned  Combat  Air  System 
Carrier-Demonstration 
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Unmanned  Carrier  Launched  Airborne 
Surveillance  and  Strike  System 

USMC  STUAS 

United  States  Marine  Corps  Small  Tactical 
Unmanned  Aircraft 

uuv 

unmanned  undersea  vehicle 

VTUAV 

vertical  takeoff  and  landing  tactical  unmanned 
aerial  vehicle 

CHAPTER  ONE 


Big  Data:  Challenges  and  Opportunities 


U.S.  Navy  intelligence,  surveillance,  and  reconnaissance  (ISR)  func¬ 
tions  have  become  critical  to  U.S.  national  security  over  the  last  two 
decades.^  Within  the  Navy,  there  is  a  growing  demand  for  ISR  data 
from  drones  and  other  sources  that  provide  situational  awareness, 
which  helps  Navy  vessels  avoid  collisions,  pinpoint  targets,  and  per¬ 
form  a  host  of  other  mission-critical  tasks.  Despite  the  battle-tested 
value  of  ISR  systems,  however,  the  large  amount  of  data  they  gener¬ 
ate  has  become  overwhelming  to  Navy  analysts.  As  the  Intelligence 
Science  Board  wrote  in  2008,  referring  to  the  entire  Department  of 
Defense  (DoD),  “the  number  of  images  and  signal  intercepts  are  well 
beyond  the  capacity  of  the  existing  analyst  community,  so  there  are 
huge  backlogs  for  translators  and  image  interpreters,  and  much  of  the 
collected  data  are  never  reviewed.”^  This  is  a  good  description  of  the 
Navy’s  big  data  challenge. 


^  The  Joint  Chiefs  of  Staff  defines  ISR  as  the  “synchronized,  integrated  planning  and 
operation  of  sensors,  processing,  exploitation  and  dissemination  systems  in  direct  support 
of  current  and  future  operations.”  It  also  states  that  this  is  “an  integrated  intelligence  and 
operations  function”  (Joint  Chiefs  of  Staff,  Department  of  Defense  Dictionary  of  Military  and 
Associated  Terms,  November  8,  2010,  as  amended  through  July  15,  2012). 

^  Intelligence  Science  Board,  Integrating  Sensor-Collected  Intelligence,  Washington,  D.C.: 
Office  of  the  Under  Secretary  of  Defense  for  Acquisition,  Technology,  and  Logistics,  Novem¬ 
ber  2008. 
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What  Is  ^^Big  Data"? 

Although  the  term  big  data  is  popular,  there  is  no  standard  definition. 
As  the  following  list  demonstrates,  different  organizations  use  the  term 
to  mean  a  wide  variety  of  things: 

•  Forrester:  “Techniques  and  technologies  that  make  handling  data 
at  extreme  scale  affordable.” 

•  Gartner:  “High  volume,  velocity  and  variety  information  assets 
that  demand  cost-effective,  innovative  forms  of  information  pro¬ 
cessing  for  enhanced  insight  and  decision  making.” 

•  IBM:  “More  than  simply  a  matter  of  size  ...  an  opportunity  to 
find  insights  in  new  and  emerging  types  of  data  and  content,  to 
make  your  business  more  agile,  and  to  answer  questions  that  were 
previously  considered  beyond  your  reach.” 

•  Office  of  the  Director  of  National  Intelligence:  “A  concept  to 
enable  mass  analytics  within  and  across  the  data  (within  the  con¬ 
fines  of  the  security  policies)  to  enable  information  integration 
(e.g.,  entity  correlation).” 

•  McKinsey:  “Datasets  whose  size  is  beyond  the  ability  of  typical 
database  software  tools  to  capture,  store,  manage,  and  analyze.” 

•  Wikipedia:  “A  collection  of  data  sets  so  large  and  complex  that  it 
becomes  difficult  to  process  using  on-hand  database  management 
tools.” 

•  ZDNet:  “Technologies  and  practice  of  handling  data  sets  so  large 
that  conventional  database  management  systems  cannot  handle 
them  efficiently  and  sometimes  cannot  handle  them  at  all.”^ 

In  our  view,  big  data  is  a  data  set  so  vast  that  it  stresses  the  limits 
of  traditional  (i.e.,  relational)  databases  along  four  parameters: 

•  volume  of  data 

•  variety  of  formats,  sources,  and  types 

•  velocity  of  searches  and  data  retrieval 

•  veracity  of  conclusions  based  on  data. 


^  All  definitions  are  as  quoted  in  Office  of  Naval  Research,  “Big  Data  Tutorial,”  vl.OO,  slide 
deck,  February  21,  2012. 
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How  Big  Is  Big? 

To  understand  how  big  “big  data”  is,  think  about  the  volume  of  infor¬ 
mation  contained  in  the  Library  of  Congress,  one  of  the  world  s  larg¬ 
est  libraries  in  terms  of  shelf  space  and  number  of  books.  All  of  the 
information  in  the  Library  of  Congress  could  be  digitized  into  200 
terabytes,  or  200  trillion  bytes.  Then  consider  the  fact  that  the  Navy 
currently  collects  the  equivalent  of  a  Library  of  Congress’  worth  of  data 
almost  every  other  day.^  But  even  this  amount  is  miniscule  compared 
with  the  size  of  the  entire  “digital  universe,”  which  is  billions  of  tera¬ 
bytes  large  and  constantly  growing.  ^  Estimates  of  the  annual  growth  of 
this  universe  vary,  but  it  appears  to  be  exponential  (Figure  1.1). 


The  Navy's  Big  Data  Challenge 

Technically,  the  amount  of  data  that  can  be  stored  by  traditional  data¬ 
bases  is  unlimited.  However,  the  greater  the  volume  of  data  being  col¬ 
lected  and  shared,  the  more  difficult  mining,  fusing,  and  effectively 
using  the  data  in  a  timely  manner  become.  In  the  Navy,  where  analysts 
use  data  to  create  information  that  informs  decisionmaking,  this  chal¬ 
lenge  is  particularly  troublesome.  All  of  the  data  and  information  col¬ 
lected  by  the  Navy  is  potentially  useful,  but  processing  it  and  deriving 
useful  knowledge  from  it  is  severely  taxing  the  analytical  capabilities 


^  Programs,  Management,  Analytics  &  Technologies,  “Maritime  ISR  Enterprise  Acquisi¬ 
tion  (MIEA)  Review,”  white  paper,  January  2011.  One  estimate  from  IBM,  cited  by  the  Navy 
and  others,  is  that  2.5  quintillion  bytes  of  data  (2.5x10^^)  are  created  every  day  from  public, 
private,  and  government  sources  (IBM,  “IBM  Study:  Digital  Era  Transforming  CMO’s 
Agenda,  Revealing  Gap  in  Readiness,”  IBM  news  release,  October  11,  2011). 

^  The  digital  universe  is  “every  electronically  stored  piece  of  data  or  file”  (Joe  McKendrick, 
“Data  Explosion:  Enough  to  Fill  DVDs  Stretching  to  the  Moon  and  Back,”  SmartPlanet. 
com.  May  14,  2010b).  This  includes  “images  and  videos  on  mobile  phones  uploaded  to  You¬ 
Tube,  digital  movies  .  .  .  ,  banking  data  swiped  [at]  an  ATM,  security  footage,  subatomic 
collisions  recorded  by  the  Large  Hadron  Collider  .  .  .  ,  transponders  recording  highway  tolls, 
voice  calls  .  .  .  through  digital  phone  lines”  and  much  more  (Data  Science  Series,  “Digital 
Universe  Will  Grow  to  40ZB  in  2020,  with  a  62%  Share  for  Emerging  Markets,”  blog  post, 
December  13,  2012). 
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Figure  1.1 

Estimated  Size  of  the  Digital  Universe 
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SOURCES:  John  Gantz,  David  Reinsel,  Christopher  Chute,  Wolfgang  Schlichting,  John 
McArthur,  Stephen  Minton,  Irida  Xheneti,  Anna  Toncheva,  and  Alex  Manfrediz,  The 
Expanding  Digital  Universe:  A  Forecast  of  Worldwide  Information  Growth  Through 
2010,  IDC  Digital  Universe  Study,  March  2007;  John  Gantz,  Christopher  Chute,  Alex 
Manfrediz,  Stephen  Minton,  David  Reinsel,  Wolfgang  Schlichting,  and  Anna  Toncheva, 
The  Diverse  and  Exploding  Digital  Universe:  An  Updated  Forecast  of  Worldwide 
Information  Growth  Through  2011,  IDC  Digital  Universe  Study,  March  2008;  John 
Gantz  and  David  Reinsel,  As  the  Economy  Contracts,  the  Digital  Universe  Expands, 

IDC  Digital  Universe  Study,  May  2009;  John  Gantz  and  David  Reinsel,  The  Digital 
Universe  Decade:  Are  You  Ready?  IDC  Digital  Universe  Study,  May  2010;  John  Gantz 
and  David  Reinsel,  Extracting  Value  from  Chaos,  IDC  Digital  Universe  Study,  June  2011; 
John  Gantz  and  David  Reinsel,  The  Digital  Universe  in  2020:  Big  Data,  Bigger  Digital 
Shadows,  and  Biggest  Growth  in  the  Far  East,  IDC  Digital  Universe  Study,  December 
2012;  Joe  McKendrick,  "Size  of  the  Data  Universe:  1.2  Zettabytes  and  Growing  Fast," 
ZDNet.com,  May  12,  2010a;  Greg  Miller,  "MQ-4C  BAMS  UAS,"  presentation  at  the 
International  Conference  on  Autonomous  Unmanned  Vehicles  2012,  February  2012; 
Chuck  Hollis,  "Charting  the  Digital  Universe:  IDC's  6th  Annual  Study,"  blog  post, 
December  11,  2012;  Saroj  Kar,  "Less  Than  1%  of  the  World's  Information  Is  Being 
Analyzed:  IDC  Report,"  Cloud  Times,  December  27,  2012. 
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of  the  Navy’s  humans  and  networks.  As  the  Navy  acquires  and  fields 
new  and  additional  sensors  for  collecting  data,  this  difficulty  will  likely 
grow  (Figure  1.2). 

Increasingly  unable  to  process  all  of  its  own  data,  the  Navy  has 
little  hope — if  nothing  changes — of  exploiting  all  of  the  potentially 
useful  data  in  the  greater  digital  universe.  Commercial,  government, 
and  other  sources,  such  as  Twitter,  GeoEye,  Inc.,  and  the  National 
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Figure  1.2 

The  Amount  of  Data  Increases  Exponentially  as  the  Navy  Acquires  New 
Sensors 
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VTUAV  =  vertical  takeoff  and  landing  tactical  unmanned  aerial  vehicle. 
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Oceanic  and  Atmospheric  Administration  (to  name  but  a  few),  create 
hundreds  of  terabytes  of  potentially  useful  data  every  day.  But  how 
much  of  these  data  can  the  Navy  expect  to  make  use  of? 


The  Navy's  Big  Data  Opportunity 

ISR  systems  are  highly  valued  across  the  military  for  good  reasons.^ 
The  data  they  collect  provide  commanders  with  information  on  enemy 
positions  and  activities.  They  enable  warfighters  to  locate  targets  with 
precision.  They  provide  vital  information  about  the  location  of  friendly 


^  In  the  literature,  the  terms  value  and  variability  have  been  associated  with  properties  of 
big  data  and  thus  correspond  to  the  Navy  opportunities  we  described  in  the  next  chapter.  See 
Yuri  Demchenko,  “Defining  the  Big  Data  Architecture  Framework  (BDAF),”  presentation 
to  the  University  of  Amsterdam,  July  14,  2013. 
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forces.  Former  U.S.  Air  Force  intelligence  lead  Lt  Gen  David  A. 
Deptula  (ret.)  has  predicted  that  ISR  will  “lead  in  the  fight”  in  2020. 
He  has  also  suggested  that  “ISR  is  currently  moving  from  a  support¬ 
ing  capability  to  the  leading  edge  of  national  security  operations.”^  As 
the  next  chapter  argues,  the  Navy  sees  data  collected  through  ISR  as 
essential  to  situational  awareness,  which  it  considers  a  vital  technologi¬ 
cal  advantage.  Essentially,  the  Navy  hopes  to  realize  the  Office  of  the 
Director  of  National  Intelligence  s  definition  of  big  data\  the  enabling 
of  “mass  analytics  within  and  across  data  ...  to  enable  information 
integration.” 


^  David  Deptula,  ‘TSR  Will  Lead  the  Fight  by  2020,”  Breaking  Defense,  June  24,  2011. 


CHAPTER  TWO 


What  the  Navy  Wants  from  Big  Data 


The  Navy’s  ISR  cycle  (consisting  of  tasking,  collection,  processing, 
exploitation,  and  dissemination  [TCPED])  is  not  undertaken  for  its 
own  sake  but  with  a  clear,  vital  objective:  providing  the  fleet  with  situ¬ 
ational  awareness.  In  military  operations,  knowledge  is  power.  In  the 
Navy,  it  is  situational  awareness — derived,  in  part,  from  ISR  data — 
that  gives  commanders  that  power  by  helping  them  answer  four  critical 
questions: 

•  Where  am  I? 

•  Where  are  my  friends? 

•  Where  is  the  enemy? 

•  Where  is  everyone  else? 

As  the  rest  of  this  chapter  demonstrates,  an  inability  to  answer  any  of 
these  four  questions  can  be  disastrous. 


Where  Am  I? 

In  January  2013,  the  USS  Guardian,  a  minesweeper,  ran  aground  in 
the  Philippines  on  Tubbataha  Reef,  a  United  Nations  Educational, 
Scientific  and  Cultural  Organization  World  Heritage  site  (Figure  2.1). 
The  vessel  was  stranded  for  months  and,  after  the  Navy  determined  it 
could  not  be  recovered,  was  cut  from  the  reef  in  three  pieces  and  thus 
destroyed. 
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Figure  2.1 

The  USS  Guardian,  Stranded 


SOURCE;  U.S.  Navy  photo. 
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The  Navy’s  investigation  of  the  incident  concluded  that  the  crew 
had  relied  on  inaccurate  maps  and  were  unable  to  reconcile  the  differ¬ 
ences  between  their  maps  of  the  area  and  more-refined  coastal  charts.^ 
(According  to  another  report,  the  National  Geospatial-Intelligence 
Agency  misplaced  a  reef  in  the  Philippine  Islands  by  eight  miles  on  its 
digital  nautical  charts — a  mistake  due  to  “erroneous  commercial  sat¬ 
ellite  imagery.”^)  In  sum,  the  crew  was  unable  to  assess  the  data  they 
had  in  a  way  that  would  have  allowed  them  to  determine  their  own 
location  with  accuracy.  As  a  result,  the  ship  was  lost,  despite  a  costly 
salvage  operation. 


^  U.S.  Pacific  Fleet  Public  Affairs,  “USS  Guardian  Grounding  Investigation  Results 
Released,”  June  20,  2013. 

^  Bob  Brewin,  “How  a  Misplaced  Reef  on  a  Digital  Gbart  Destroyed  a  Navy  Minesweeper,” 
Nextgov.com,  August  5,  2013. 
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Where  Are  My  Friends? 

In  March  2009,  the  USS  Hartford,  a  submarine,  collided  with  the 
USS  New  Orleans,  an  amphibious  transport  ship,  in  the  Strait  of 
Hormuz  (Figure  2.2).  Fifteen  sailors  were  injured,  thousands  of  gal¬ 
lons  of  diesel  were  spilled,  and  $100  million  in  damage  was  done.^  A 
senior  Navy  officer  attributed  part  of  the  blame  to  analysts’  inability 
to  discern  among  a  number  of  radar  contacts:  “There  were  a  whole  lot 
of  watchstanders  that  failed  to  recognize  the  sensor  data  presented  to 
them.”^ 


Figure  2.2 

The  Aftermath  of  the  USS  New  Orleans  and  USS  Hartford  Collision 


SOURCE:  U.S.  Navy  photo  by  CDR  Jane  Campbell. 
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^  “U.S.  Navy  Vessels  in  Bahrain  for  Evaluation  After  Collision,”  CNN.com,  March  21, 
2009. 

^  Andrew  Scutro,  “Admiral:  Complacency  Caused  Sub  Collision,”  Navy  Times,  October 
29,  2009. 
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Where  Is  the  Enemy? 

In  October  2000,  the  USS  Cole,  a  guided-missile  destroyer,  was 
attacked  in  the  port  of  Aden  in  Yemen.  Terrorists  pulled  a  small  boat 
to  the  vessels  side  and  waved  and  smiled  at  the  crew  before  detonating 
explosives  that  created  a  40-foot  by  40-foot  hole  in  the  destroyer  s  hull, 
killing  17  sailors  and  injuring  39  others  (Figure  2.3).  The  attack  on  the 
USS  Cole,  the  deadliest  against  a  U.S.  naval  vessel  since  the  USS  Stark 
came  under  fire  during  the  Iran-Iraq  War  in  May  19877  iriay  be  one 
of  the  most  well  known  examples  of  the  importance  of  knowing  the 
enemy’s  location. 


Figure  2.3 

The  Attack  on  the  USS  Co/e 


SOURCE:  Department  of  Defense  photo  by  Sgt.  Don  L.  Maes,  U.S.  Marine  Corps. 
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^  9/11  Memorial,  “USS  Cole  Bombing,”  web  page,  undated. 
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Where  Is  Everyone  Else? 

Awareness  of  commercial  shipping  traffic  and  other  vessels  that  are  nei¬ 
ther  friends  nor  enemies  is  also  critical.  In  August  2012,  the  USS  Porter, 
a  destroyer,  collided  with  a  commercial  oil  tanker  in  the  middle  of 
the  night  in  the  Strait  of  Hormuz  (Figure  2.4).  The  exact  cause  of  the 
collision  has  not  yet  been  reported  in  open  sources,  but  audio  from 
the  bridge  of  the  USS  Porter  suggests  that  navigation  errors  may  have 
played  a  significant  role.  Improved  situational  awareness  might  have 
prevented  this  mishap. 


Figure  2.4 

The  USS  Porter  Collision 


SOURCE:  U.S.  Navy  photo  by  Mass  Communication  Specialist  Srd  Class 
Jonathan  Sunderman. 
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Situational  Awareness:  A  Vital  Goal 

As  the  examples  provided  in  this  chapter  demonstrate,  situational 
awareness  is  critical  to  naval  operations,  and  the  Navy  needs  to  improve 
its  ability  to  make  sense  of  the  data  that  growing  numbers,  and  grow¬ 
ing  varieties,  of  sensors  provide.  Indeed,  as  the  Intelligence  Science 
Board  reported  in  2008,  “integrating  data  from  different  sensors  and 
platforms”  could  “dramatically  enhance”  geolocation  and  other  impor¬ 
tant  tasks. ^  So  what,  exactly,  is  preventing  the  Navy  from  reaping  the 
benefits  of  ISR-provided  data?  The  next  chapter  argues  that  two  main 
factors  are  at  play. 


^  Intelligence  Science  Board,  2008. 


CHAPTER  THREE 


Barriers  to  Benefiting  from  Big  Data 


As  we  have  argued  in  previous  chapters,  today  s  ISR  capabilities  have 
the  potential  to  enhance  the  state  of  naval  situational  awareness.  How¬ 
ever,  the  Navy  needs  to  improve  its  ability  to  make  sense  of  the  data 
being  collected.  In  particular,  it  faces  two  challenges:  timely  consump¬ 
tion  and  accurate  integration. 


Timely  Consumption 

In  2020,  there  could  be  twice  as  many  fielded  unmanned  ISR  platforms 
and  related  sensors  as  there  are  today  in  early  2014  (Figure  3.1).  One 
such  platform  is  the  MQ-4C  Triton,  a  UAV  developed  under  the  Broad 
Area  Maritime  Surveillance  (BAMS)  program  and  designed  to  fly  sur¬ 
veillance  missions  of  up  to  24  hours  at  altitudes  of  more  than  10  miles 
(Figure  3.2).^  Existing  and  emerging  unmanned  platforms  will  join 
a  host  of  manned  platforms  (including  the  P-8  Poseidon,  shown  in 
Figure  3.3)  and  national  assets  (a  variety  of  monitoring  technologies 
known  as  National  Technical  Means)  that  carry  sensor  packages.  Each 
of  these  platforms  is  capable  of  generating  enormous  amounts  of  data 
in  a  single  mission  or  day.  For  example,  the  Office  of  Naval  Research 
reported  in  2012  that  a  BAMS  UAV  can  collect  10-20  terabytes  per 
mission.^ 


^  Naval  Air  Systems  Command  Public  Affairs,  “Navy  Triton  Unmanned  Aircraft  System 
Completes  First  Flight,”  story  number  NNS130522-20,  2013. 

^  Office  of  Naval  Research,  2012.  These  numbers  are  likely  to  be  even  larger  in  the  future. 
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Figure  3.1 

Anticipated  Growth  in  UAV  Sensor  Platforms 


I  UCAS-D 
I  BAMS-D 
I  Shadow 

I  Scan 
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I  Fire 
Scout 

I  USMC 
STUAS 

I  STUAS 
I  BAMS 
I  UCLASS 


Number  of  sensor  platforms 

SOURCE:  Card,  2012. 

NOTE:  BAMS  =  Broad  Area  Maritime  Surveillance;  BAMS-D  Broad  Area  Maritime 
Surveillance  System-Demonstrator;  STUAS  =  Small  Tactical  Unmanned  Aircraft 
System;  UCAS-D  =  Unmanned  Combat  Air  System  Carrier-Demonstration;  UCLASS  = 
Unmanned  Carrier  Launched  Airborne  Surveillance  and  Strike  System;  USMC  STUAS  = 
United  States  Marine  Corps  Small  Tactical  Unmanned  Aircraft.  Additional  information 
on  these  platforms  can  be  found  in  Porche  et  al.,  2013. 
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Unfortunately,  much  of  the  data  collected  by  ISR  platforms  never 
reaches  the  analysts  who  need  to  see  it — in  fact,  as  little  as  5  percent 
may  be  getting  through.  In  the  case  of  analysts  working  afloat  on  ships, 
a  large  part  of  the  problem  is  extremely  slow  download  times  caused 
by  bandwidth  and  connectivity  limitations.  Whereas  an  ashore  ana¬ 
lyst  working  with  a  100-gigabits-per-second  transfer  speed  can  down¬ 
load  a  terabyte  of  data  in  four  minutes,  an  afloat  analyst  working  with 
a  40-megabits-per-second  transfer  speed  needs  three  days  to  do  so 
(Table  3.1). 

Compounding  the  download-time  challenge  are  two  additional 
factors.  First,  the  communications  pipelines  used  by  the  analysts  are 
sometimes  outside  their  control.  For  example,  access  to  a  satellite  com¬ 
munications  channel  may  be  shared  with  others  and,  based  on  regional 
or  national  priorities,  may  be  unavailable  for  a  Navy  analysts  use. 
Second,  analysts  must  often  download  multiple  pieces  of  large  data 
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Figure  3.2 

The  MQ-4C  Triton  UAV 


SOURCE:  U.S.  Navy  photo,  courtesy  of  Northrop  Grumman. 
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Figure  3.3 
The  P-8  Poseidon 


SOURCE:  U.S.  Navy  photo. 
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Table  3.1 

Download  Times  for  One  Terabyte 


Service 

Max  Transfer  Speed 
(in  bits  per  second) 

Download 
Time  in 
Seconds 

Download 
Time  in 
Minutes 

Download 
Time  in 
Hours 

Download 
Time  in 
Days 

100-gigabits- 

per-second 

service 

40,000,000,000 

220 

4 

NA 

NA 

40-gigabits-per- 
second  service 

16,000,000,000 

550 

9 

NA 

NA 

Large  Data 

10-gigabits-per 

second  Joint 

Capability 

Technology 

Demonstration^ 

8,500,000,000 

1,035 

17 

NA 

NA 

10-gigabits-per- 
second  service 

4,000,000,000 

2,199 

37 

<1 

NA 

155-megabits- 

per-second 

service 

62,000,000 

141,872 

2,365 

39 

2 

50-megabits- 

per-second 

Wideband 

Global  Satellite 

communications 

channel*^ 

40,000,000 

212,902 

3,665 

61 

3 

SOURCE:  Programs,  Management,  Analytics  &  Technologies,  2011. 

^The  Large  Data  Joint  Capability  Technology  Demonstration  researched  bandwidth 
efficiency  in  order  to  support  large  transfers  of  data. 

^  A  50-megabit-per-second  Wideband  Global  Satellite  communications  channel  is  a 
dedicated  satellite  communications  channel  used  by  afloat  analysts. 


(such  as  high-resolution  images)  to  find  exactly  what  they  need.  This 
is  because  many  of  the  large  pieces  of  data  generated  by  ISR  sensors 
(including  imagery,  video,  and  audio)  are  “untagged,”  meaning  that 
they  are  unaccompanied  by  information  that  would  help  analysts  find 
them  and  decide  whether  to  access  them.  Demand  management,  dis¬ 
cussed  in  Chapter  Five,  could  alleviate  some  of  the  burden  on  analysts, 
but,  in  cases  where  data  cannot  be  tagged,  the  raw  images  must  be 
downloaded,  and  slow  download  times  once  again  come  into  play.  In 
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sum,  most  of  the  time,  analysts  do  not  have  the  luxury  of  receiving  the 
“right”  data  in  a  timely  fashion. 


Accurate  Integration 

Navy  analysts  are  confronted  with  a  wide  variety  of  data  streaming  in 
from  different  ISR  platforms  and  sensors — data  they  must  integrate 
to  ensure  accurate,  comprehensive  situational  awareness.  As  Figure  3.4 
shows,  these  data  come  from  multiple  types  of  intelligence  sources.  To 
access  and  make  sense  of  the  data,  many  analysts  sit  at  workstations 
comprising  multiple  screens,  each  showing  different  streams  of  data 
and  each  loaded  with  different  suites  of  tools  (Figure  3.5).  In  many 


Figure  3.4 

Diverse  Data  Sources 
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intelligence 


SOURCE;  U.S.  Navy  photo  by  Mass  Communication  Specialist  3rd  Class 
Brooks  B.  Patton  Jr. 
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Figure  3.5 

An  Analyst  Workstation 


SOURCE:  U.S.  Navy  photo  by  Mass  Communication  Specialist  Seaman 
K.  Cecelia  Engrums. 

RAND  RR31 5-3.5 


cases,  the  applications,  databases,  and  operating  systems  underlying 
these  tools  are  produced  by  different  vendors  and  are  not  interoperable. 
Sailors  told  us  that  they  are  overwhelmed  as  they  struggle  to  master  the 
functions  provided  by  each  tool  in  the  suite  at  their  workstations.  The 
ability  to  fuse  multiple  intelligence  types  in  a  timely  manner  is  a  known 
gap  that  the  Distributed  Common  Ground  System-Navy  (DCGS-N) 
Increment  2  program  of  record  is  required  to  close. 

A  second  challenge  is  the  existence  of  multiple  and  often  mutu¬ 
ally  exclusive  security  domains  (Figure  3.6).  Some  ISR  platforms  are 
designed  to  feed  all  of  their  data  into  a  specific  database  that  resides  in  a 
specific,  isolated  security  domain,  regardless  of  whether  all  of  the  indi¬ 
vidual  pieces  of  data  collected  by  that  platform  really  need  to  be  classi¬ 
fied  at  that  particular  level.  Some  specific  databases  (and,  by  extension, 
the  data  contained  within  them)  are  accessible  only  through  a  specific 
network,  meaning  that  it  is  possible  for  a  Secret-level  piece  of  data  to 
reside  in  a  Top  Secret-level  database  that  is  accessible  only  through  a 
Top  Secret  network.  For  analysts,  this  means  that  searching  for  a  single 
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Figure  3.6 

Security  Domains  Today 


SOURCE:  Office  of  Naval  Research,  2012. 

NOTE:  TS/SCI  =  Top  Secret/Sensitive  Compartmented  Information. 
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piece  of  data  can  require  them  to  use  multiple  networks  to  access  mul¬ 
tiple  databases — a  dampener  on  productivity  and  a  dangerous  situa¬ 
tion,  given  that  achieving  accurate  situational  awareness  requires  inte¬ 
grating  data  from  multiple  sources  in  a  timely  fashion. 

We  know  from  a  study  of  the  Afghan  Mission  Network,  which 
was  used  during  Operation  Enduring  Freedom,  that  improved  collabo¬ 
ration  can  occur  when  the  number  of  security  domains  is  reduced.^  One 
approach  to  enabling  the  consolidation  of  security  domains  is  found  in 


^  Chad  C.  Serena,  Isaac  R.  Porche  III,  Joel  B.  Predd,  Jan  Osburg,  and  Bradley  Lossing,  Les¬ 
sons  Learned  from  the  Afghan  Mission  Network:  Developing  a  Coalition  Contingency  Network, 
Santa  Monica,  Calif.:  RAND  Corporation,  forthcoming.  The  Afghan  Mission  Network 
enabled  the  United  States  and  its  allies  in  Afghanistan  to  subsume 

their  own  internal  secret  communications  networks  in  favor  of  a  common  network  for 
managing  command  and  control  and  sharing  intelligence,  surveillance  and  reconnais¬ 
sance  information.  .  .  .  [T]o  implement  the  Afghanistan  Mission  Network,  which  cre¬ 
ates  a  common  operating  picture  for  all  U.S.  and  NATO  [North  Atlantic  Treaty  Orga¬ 
nization]  commanders  in  Afghanistan,  the  U.S.  military  had  to  undergo  a  shift  in  the 
way  it  manages  its  Secret  IP  [Internet  Protocol]  Router  Network.  (Barry  Rosenberg, 
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the  Apache  Accumulo  project  (previously  called  Cloudbase)  incubated 
by  the  National  Security  Agency.  Apache  Accumulo  facilitates  security 
domain  consolidation  by  allowing  cell-level  security-tagging  mecha¬ 
nisms  for  database  entries.  Essentially,  this  means  that  each  piece  of 
data  in  the  database  is  tagged  with  its  specific  classification  level.  Once 
this  information  is  present,  access-control  techniques  can  be  used  to 
limit  or  grant  access  to  that  piece  of  data  based  on  a  user  s  security 
credentials.^  In  the  Navy,  the  progression  to  a  single  security  domain 
might  look  something  like  Figure  3.7.  Ultimately,  the  goal  would  be  to 
create  a  single  network  domain  that  provides  access  to  data  at  multiple 
levels  of  security  classification. 


How  Analysts  Cope  Today 

We  have  shown  that  Navy  analysts  are  struggling  with  the  timely  con¬ 
sumption  and  accurate  integration  of  big  data,  and  we  expect  their 
challenges  to  grow  as  the  Navy  fields  new  and  additional  ISR  plat¬ 
forms.  Common  wisdom  among  analysts  themselves  is  that  they  spend 
80  percent  of  their  time  looking^r  the  right  data  and  only  20  percent 
of  their  time  looking  at  the  right  data.  Unfortunately,  our  modeling 


“Battlefield  Network  Connects  Allied  Forces  in  Afghanistan,”  DefenseSystems.com, 
September  14,  2010) 

^  For  more  information,  see  Paul  Burkhardt  and  Chris  Waring,  “An  NSA  Big  Graph 
Experiment,”  presentation  at  the  Carnegie  Mellon  University  SDI/ISTC  Seminar,  Pitts¬ 
burgh,  Pa.,  May  20,  2013;  Jeremy  Kepner,  Christian  Anderson,  William  Arcand,  David 
Bestor,  Bill  Bergeron,  Chansup  Byun,  Matthew  Fiubbell,  Peter  Michaleas,  Julie  Mullen, 
David  O’Gwynn,  Andrew  Prout,  Albert  Reuther,  Antonio  Rosa,  and  Charles  Yee,  “D4M  2.0 
Schema:  A  General  Purpose  High  Performance  Schema  for  the  Accumulo  Database,”  paper 
presented  at  the  2013  IEEE  High  Performance  Extreme  Computing  Conference,  Septem¬ 
ber  12,  2013;  Oflfice  of  Naval  Research,  2012;  Isaac  R.  Porche  III,  Bradley  Wilson,  Shane 
Tierney,  Ray  Koym,  James  Dryden,  Evan  Saltzman,  Roland  J.  Yardley,  John  M.  Yurchak, 
Stephanie  Young,  Endy  M.  Daehner,  Megan  McKernan,  and  Kate  Giglio,  The  DCGS-Navy 
Increment  2  Analysis  of  Alternatives:  Options  for  Meeting  the  TCPED  Challenges  and  Opportu¬ 
nities,  Santa  Monica,  Calif.:  RAND  Corporation,  2013;  and  Jaikumar  Vijayan,  “Facebook 
Moves  30-Petabyte  Hadoop  Cluster  to  New  Data  Center,”  ComputerWorld,  July  29,  2011. 
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Figure  3.7 

Security  Domains  in  the  Future? 
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SOURCE:  U.S.  Department  of  the  Navy,  2012. 
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and  simulation  found  evidence  to  support  this  split.^  The  truth  is  that 
analysts  are  drowning  in  data,  and  the  Navy  has  limits  on  the  number 
of  analysts  it  employs.  So,  how  can  the  Navy  ensure  that  the  analysts 
it  does  employ  are  better  able  to  cope  with  big  data?  The  next  chapter 
explores  one  option:  dynamically  managing  analyst  workloads. 


^  See  Isaac  R.  Porche  III,  Evan  Saltzman,  Roland  Yardley,  and  Gordon  Lee,  “MAXINT,” 
presentation  at  the  Military  Operations  Research  Workshop  on  Analytic  Approaches  to  Air¬ 
borne  ISR,  National  Defense  University,  Ft.  McNair,  Washington,  D.C.,  April  2012;  and 
Porche  et  ah,  2013. 


CHAPTER  FOUR 


Dynamically  Managing  Analyst  Workloads 


Compared  with  the  other  military  services,  the  Navy  employs  only 
a  small  number  of  analysts.  As  of  2011,  there  were  several  thousand 
Navy  analysts  divided  among  five  intelligence  specialties  (Figure  4.1). 
It  is  important  to  understand  that,  despite  the  anticipated  growth  in 
incoming  data,  the  Navy  will  not  increase  the  number  of  analysts 
(including  intelligence  specialists)  that  it  employs.  It  is  also  important 

Figure  4.1 

Approximate  Number  of  Navy  Intelligence  Specialists  as  of  2011 


IS  3910  IS  3923  IS  3924  CTT9102  CTR9147 

(Imagery  (Targeting)  (Multiple  (Electronic  (Communications 

intelligence)  intelligence  types)  intelligence)  intelligence) 


Intelligence  type 


NOTE:  A  description  of  the  tasks  performed  by  these  analysts  is  provided  in 
Porche  et  al.,  2013. 
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to  understand  that  the  Navy’s  analysts  are  spread  around  the  world:  in 
the  Navy’s  reachback  intelligence  center,  in  maritime  operations  cen¬ 
ters,  and  afloat  on  ships  (Figure  4.2).  They  are  located  both  in  the 
United  States  and  abroad,  both  afloat  and  ashore,  working  on  large- 
deck  ships  and  “small  boys”  (e.g.,  destroyers,  cruisers). 

One  potential  way  to  increase  analyst  productivity  is  to  physically 
locate  Navy  analysts  together.  However,  RAND  modeling,  based  on 
a  year  of  operational  data,  showed  that  the  physical  location  of  Navy 
intelligence  specialists  is  not  necessarily  the  deciding  factor  in  their 
productivity.^  A  dynamically  balanced  workload  appears  to  be  much 
more  important. 

Today’s  Navy  intelligence  specialists  are,  for  the  most  part,  work¬ 
ing  on  “local  tasks,”  since  the  allocation  of  tasks  tends  to  be  based  on 
which  analysts  are  nearby  or  statically  assigned,  rather  than  on  who  is 
available  globally  to  accept  new  tasking.  In  the  main,  today’s  tasking 

Figure  4.2 

Navy  Intelligence  Specialists  Are  Distributed  Globally 


#  Ashore  #  Afloat  ^  Reachback  intelligence  center 


NOTE:  Some  locations  are  notional. 

RAND  RR315-4.2 


^  Details  are  in  Porche  et  al.,  2013. 
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arrangements  are  fixed  and  separated  based  on  geography  (Figure  4.3;  for 
more-detailed  drawings  of  the  tasking  arrangements,  see  Figure  A.l).^ 
The  main  disadvantage  of  this  arrangement  is  that  intelligence  special¬ 
ists  in  one  location  can  become  quickly  overwhelmed  with  tasks  that 
need  not  necessarily  be  assigned  to  them  but  that,  because  of  the  local 
tasking  model,  come  their  way  by  default. 

What  if  the  Navy  were  to  consider  implementing  a  regional 
(Figure  4.4)  or  even  global  (Figure  4.5)  tasking  model  instead?  In  these 
models,  tasks  would  be  automatically  shared  and  allocated  within 
regions  (or,  in  the  latter  case,  globally)  based  on  who  is  available  to 
accept  new  tasking.  RAND  researchers  developed  a  model  of  intel¬ 
ligence  specialist  productivity  and,  using  a  year  of  operational  data, 
found  that  the  regional  and  global  tasking  models  do  indeed  improve 


Figure  4.3 

Today's  Tasking  Arrangements  Are  "Local" 


#  Ashore  #  Afloat  ^  Reachback  intelligence  center 


NOTE:  Some  locations  are  notional. 

RAND  RR315-4.3 


^  This  is  not  universally  true,  however:  In  the  case  of  some  intelligence  types,  there  is  some 
reachback  to  analysts  at  the  Navy’s  reachback  intelligence  center  or  maritime  operations 


centers. 
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Figure  4.4 

Tomorrow's  Tasking  Arrangements  Could  Be  "Regional" 


#  Ashore  #  Afloat  ^  Reachback  intelligence  center 


NOTE:  Some  locations  are  notional. 
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Figure  4.5 

Tomorrow's  Tasking  Arrangements  Could  Be  "Global" 


#  Ashore  #  Afloat  ^  Reachback  intelligence  center 
NOTE:  Some  locations  are  notional. 
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intelligence  specialist  productivity.  However,  this  is  true  only  to  a  cer¬ 
tain  extent. 

Figure  4.6  shows,  at  an  abstracted  level,  how  intelligence  special¬ 
ist  productivity  changes  based  on  the  tasking  model.  In  this  case,  we 
are  considering  the  productivity  of  imagery  analysts  processing  data 
coming  from  a  Navy  BAMS  UAV.  The  y-axis  measures  how  often 
an  imagery  analyst  processes  data  in  time  to  satisfy  a  customer  (for 
instance,  a  ship  commander),  which  decreases  from  top  to  bottom.  The 
x-axis  shows  the  number  of  BAMS  UAV  orbits,  which  increases  from 
left  to  right.  As  the  figure  shows,  regional  tasking  outperforms  local 
tasking,  and  global  tasking  outperforms  both.  However,  as  the  number 
of  BAMS  UAV  orbits  increases — as  we  know  it  will — all  three  models 
eventually  dip  down,  revealing  that  imagery  analysts  simply  will  not 
be  able  to  keep  up  with  all  of  the  imagery  coming  their  way,  no  matter 
how  we  balance  their  workloads. 

Implementing  a  regional  or  global  tasking  model  might  buy  the 
Navy  a  short-term  improvement  in  analyst  productivity,  but  changes  to 
how  workloads  are  managed  are  not,  on  their  own,  a  viable  long-term 
solution.  The  next  chapter  examines  more-comprehensive  alternatives 
to  solving  the  big  data  challenge. 


Figure  4.6 

Modeling  Results:  Imagery  Analysts  (Abstracted) 
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CHAPTER  FIVE 


Alternatives  for  Dealing  with  Big  Data 


We  have  shown  that  better  management  of  analyst  workloads  is  not  a 
sufficient  or  long-term  solution  to  the  Navy’s  big  data  challenged  To 
be  complete,  a  solution  must  involve  changes  along  all  of  the  following 
four  dimensions: 

•  people 

•  tools  and  technology 

•  data  and  data  architectures 

•  demand  and  demand  management. 

This  chapter  presents  alternatives  for  dealing  with  big  data,  beginning 
with  a  description  of  the  baseline  scenario. 


Baseline 

Currently,  Navy  analysts  must  access  data  that  are  stored  in  a  number 
of  discrete,  unconnected  databases  (Figure  5.1;  for  more-detailed  draw¬ 
ings  of  the  baseline  and  alternatives,  see  Figure  A.2).^  To  do  this,  they 
must  master  and  use  many  different  desktop  applications.  To  gain 
awareness  of  the  existence  and  location  of  data  they  might  need,  they 
must  communicate  with  other  analysts  through  such  tools  as  email, 
chat  software,  and  telephone  calls.  They  face  several  challenges  as 


^  It  may  be  necessary,  but  is  not  sufficient. 

^  Note  that  this  challenge  applies  to  all  of  the  services,  not  just  the  Navy. 
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Figure  5.1 
Baseline 


RAND  RR3 15-5.1 


they  download,  assess,  and  make  sense  of  raw  data.  For  instance,  as 
explained  in  Chapter  Three,  download  times  are  often  quite  slow,  espe¬ 
cially  afloat.  Collaboration  and  integration  generally  take  place  manu¬ 
ally  rather  than  in  an  automated  fashion.  Many  different  data  types 
need  to  be  integrated. 

People.  In  the  baseline  scenario,  the  Navy  does  not  increase  the 
number  of  analysts  it  employs.  (In  fact,  the  number  of  afloat  analysts 
decreases  in  both  the  baseline  and  all  of  the  alternatives.)  In  general. 
Navy  analysts  in  the  baseline  scenario  continue  to  work  on  tasking  that 
is  developed  and  assigned  locally  or  in  accordance  with  static,  fixed 
arrangements.  There  are  some  fixed  work-sharing  arrangements,^  but 
there  is  no  dynamic,  real-time  tasking  of  exploitation  or  other  tasks. 

Tools  and  technology.  The  current  architecture  and  environ¬ 
ment  continue  to  set  limits  on  developers’  ability  to  easily  incorporate 
new  tools  or  systems  because  there  is  no  service-oriented  architecture 
(SOA)  or  application-integration  framework  that  simplifies  the  process 
of  adding  new  applications.^ 


^  This  includes  so-called  imagery  federations. 

^  An  SOA  is  an  architectural  style.  Simply  described,  it  is  an  architecture  consisting  of  ser¬ 
vice  providers  and  service  consumers  that  enables  business  agility  through  the  use  of  loosely 
coupled  services.  Services  are  implementation-independent  reusable  business  functions  that 
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Data  and  database  architecture.  In  the  baseline  scenario, 
numerous  stovepiped  datasets  and  numerous  security  domains  persist. 
The  result  is  a  level  of  system  interoperability  that  is  marginal.  “Con¬ 
nected  interoperability”  exists,  but  mostly  between  homogeneous  sys¬ 
tems.  Manual  exchanges  are  still  required.  Databases  remain  separated, 
each  relying  on  traditional  relational  databases  that  support  separate 
applications,  separate  services,  and  separate  catalogs.  The  environment 
scores  poorly  (a  “1”)  on  the  levels  of  information  systems  interoperabil¬ 
ity  (LIST)  scale  shown  in  Table  5.1. 

Demand  management.  For  the  purposes  of  analysis,  the  baseline 
scenario  and  all  three  alternatives  assume  a  judicious  collection  of  intel¬ 
ligence.  For  example,  sensors  are  smartly  cued  to  targets,  meaning  that 
sensors  are  turned  on  only  as  needed  rather  than  left  on  continuously. 
Sensors  cued  to  the  target  send  more-relevant  data  and  thus  lower  bur¬ 
dens  on  bandwidth  and  on  analysts’  cognitive  reserves. 


Alternative  1:  Applications  (Adding  More  Tools  to  the 
Baseline) 

We  call  the  first  alternative  to  the  baseline  the  applications  alternative 
because  one  of  its  primary  enhancements  relative  to  the  baseline  is  to 
add  more  applications  to  analyst  workstations  (Figure  5.2).  This  aims 
to  help  analysts  take  advantage  of  the  increased  variety  of  data  afforded 
by  the  proliferation  of  data  types  and  databases.  It  does  not  represent 
any  significant  design  or  development  activities  relative  to  the  baseline 
but  rather  adds  current  and  emerging  DoD  and  Intelligence  Commu¬ 
nity  (IC)  tools  to  address  specific  identified  capability  gaps. 

People.  As  in  the  baseline  scenario,  the  Navy  does  not  increase 
the  number  of  analysts  it  employs.  However,  alternatives  1,  2,  and  3 


are  discovered  as  self-describing  interfaces  and  invoked  using  open-standard  protocols  across 
networks  (Isaac  R.  Porche  III,  James  Dryden,  Kathryn  Connor,  Bradley  Wilson,  Shawn 
McKay,  Kate  Giglio,  and  Juan  Montelibano,  Finding  Services  for  an  Open  Architecture:  A 
Review  of  Existing  Applications  and  Programs  in  PEO  C4P  Santa  Monica,  Calif.:  RAND 
Corporation,  MG-1071-NAVY,  2011).  SOA  principles  enable  developers  to  aggregate  and 
abstract  interfaces,  thereby  reducing  the  number  of  interfaces  required. 
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Table  5.1 

Levels  of  Information  Systems  Interoperability  Scale 


Level 

Description 

Information  Exchange 

Level  4: 
Enterprise 

Interactive 

manipulation;  shared 
data  and  applications 

Distributed  global  information  and 
applications;  simultaneous  interactions  with 
complex  data;  advanced  collaboration  (e.g., 
interactive  COP  update);  event-triggered  global 
database 

Level  3: 
Domain 

Shared  data; 

"separate" 

applications 

Shared  databases;  sophisticated  collaboration 
(e.g.,  COP) 

Level  2: 
Functional 

Minimal  common 
functions; 
separate  data  and 
applications 

Heterogeneous  product  exchange;  basic 
collaboration;  group  collaboration  (e.g., 
exchange  of  annotated  imagery,  maps  with 
overlays) 

Level  1: 
Connected 

Electronic  connection; 
separate  data  and 
applications 

Homogeneous  product  exchange  (e.g., 
voice,  tactical  data  links,  text  files,  transfers, 
messages,  email) 

Level  0: 
Isolated 

Not  connected 

Manual  gateway  (e.g.,  diskette,  tape,  hard-copy 
exchange) 

SOURCE:  Adapted  from  C4ISR  Architectures  Working  Group,  "Levels  of  Information 
Systems  Interoperability  (LISI),"  1998,  Figure  2-5. 

NOTE:  COP  =  common  operational  picture. 


involve  greater  usage  of  ashore  analysts — an  arrangement  known  as 
reachback‘^ — relative  to  the  baseline  (although  afloat  analytic  capa¬ 
bilities  are  maintained).  They  also  assume  that  the  Navy  chooses  to 
dynamically  manage  analyst  workflow  (either  regionally  or  globally). 
The  motivation  for  this  shift  is  rooted  in  decades-old  initiatives  to 
manage  DoD  end-strength.^ 


^  Reachback  is  the  “process  of  obtaining  products,  services,  and  applications,  or  forces,  or 
equipment,  or  material  from  organizations  that  are  not  forward  deployed”  (Joint  Chiefs  of 
Staff,  2012). 

^  In  2003,  tben-Secretary  of  Defense  Donald  Rumsfeld  exhorted  the  military  services  to 
explore  options  to  reduce  the  footprint  of  forward-deployed  forces  in  an  effort  to  reduce 
“both  the  number  of  forces  deployed  as  well  as  the  rotation  base  multiple  needed  to  maintain 
that  number  of  troops  forward-deployed”  (U.S.  Secretary  of  Defense,  “Action  Agenda  to 
Support  ‘End  Strength’  Memo  Tasks,”  memorandum,  August  25,  2003). 
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Figure  5.2 

Alternative  1:  Applications 


RAND  RR315-5.2 


Tools  and  technology.  The  Navy  adds  applications  as  discrete 
modules  to  address  a  number  of  existing  capability  gaps.  These  appli¬ 
cations  provide  analysts  with  the  additional  capabilities  they  need 
to  exploit  the  volume  and  variety  of  imagery  and  other  sensor  data 
coming  from  UAVs  and  other  sources  that  support  maritime  domain 
awareness. 

Data  and  architecture.  The  Navy  adopts  software  that  enables 
more  interoperability  (specifically,  a  functional  interoperability  that 
helps  heterogeneous  applications  exchange  data).^  This  is  a  slight 
improvement  over  the  baseline,  scoring  a  “2”  on  the  LISI  scale. 

Demand  management.  For  the  purposes  of  analysis,  the  base¬ 
line  scenario  and  all  three  alternatives  assume  a  judicious  collection  of 
intelligence. 


^  An  example  of  this  software  is  the  Joint  Enterprise  Modeling  and  Analytics  (JEMA)  tool. 
JEMA,  developed  by  the  National  Security  Agency,  is  used  by  analysts  in  the  IC.  It  runs  in 
windows  and  allows  users  to  record  and  save  workflows  (e.g.,  “keystrokes”  for  accessing,  pre¬ 
paring,  and  manipulating  data)  as  executables  that  can  be  reused  and  repeated. 
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Alternative  2:  Consolidation  (Adopt  a  Service-Oriented 
Environment) 

We  call  the  second  alternative  to  the  baseline  the  consolidation  alterna¬ 
tive  because  it  primarily  concerns  itself  with  consolidation  of  applica¬ 
tions  and  their  corresponding  data  and  databases  (Figure  5.3).  This 
alternative  is  built  around  an  SOA,^  which  can  host  web  services  that 
can  be  built  to  run  within  a  common  browser  and  shared  with  part¬ 
ners  in  other  agencies  and  services.  The  idea  is  to  move  away  from 
the  development  of  separate  applications  and  to  enable  many  different 
analysts  to  access  capabilities  more  broadly.  This  alternative  represents 

Figure  5.3 

Alternative  2:  Consolidation 


Browser 


1 


Browser 


Analyst 


Browser 


NOTE:  This  figure  shows  the  consolidation  that  can  be  accomplished  at 
the  user-interface  level  (via  browser).  We  do  not  mean  to  imply  that 
browsers  are  necessarily  directly  connected  to  data  without  some 
intermediary  capability  (such  as  an  analytic  engine). 
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^  The  Navy’s  Consolidated  Afloat  Networks  and  Enterprise  Services  (CANES)  program 
of  record  intends  to  provide  a  shipboard  SOA  along  with  the  ability  to  host  shared  software 
services.  CANES  is  touted  as  the  Navy’s  “next  generation  of  networks  and  computing  infra¬ 
structure,  primarily  for  use  on  ships.  The  system  consists  of  hardware,  operating  systems, 
virtualization  software,  system  management  software,  and  numerous  applications”  (Jessie 
Riposo,  John  Gordon  IV,  Robert  Murphy,  Bradley  Wilson,  and  Isaac  R.  Porche  III,  CANES 
Contracting  Strategies  for  Full  Deployment,  Santa  Monica,  Calif:  RAND  Corporation,  TR- 
993-NAVY,  2012). 
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significant  design  and  development  geared  toward  the  integration  of 
new  and  existing  tools,  enabling  a  high  level  of  interoperability.^  Multi¬ 
intelligence  fusion  and  end-to-end  workflow  automation  result. 

People.  As  in  the  baseline  scenario,  the  Navy  does  not  increase 
the  number  of  analysts  it  employs.  However,  alternatives  1,  2,  and  3 
employ  greater  usage  of  ashore  analysts  relative  to  the  baseline.  They 
also  assume  that  the  Navy  chooses  to  dynamically  manage  analyst 
workflow. 

Tools  and  technology.  Capability  is  provided  by  software  in  the 
form  of  web  services  and  widgets  that  bridge  identified  gaps.^®  The 
number  of  interfaces  required  is  equal  to  or  less  than  the  number  of 
interfaces  required  in  either  alternative  1  or  the  baseline  scenario. 

Data  and  architecture.  This  consolidation  alternative  assumes  a 
high  level  of  interoperability  specifically  enabled  by  an  open  architec¬ 
ture  (for  applications)  and  a  fusion  brain  (for  the  data).^^  This  improve¬ 
ment  scores  a  “3”  on  the  LISI  scale. 

Demand  management.  For  the  purposes  of  analysis,  the  base¬ 
line  scenario  and  all  three  alternatives  assume  a  judicious  collection  of 
intelligence. 


Alternative  3:  Cloud  (Join  the  Distributed  Cloud) 

The  third  and  final  alternative  moves  data,  databases,  applications,  wid¬ 
gets,  services,  and  other  elements  into  a  cloud  architecture  (Figure  5.4). 
Used  generally,  the  term  cloud  refers  to  many  different  ways  of  sharing 
data,  tools,  or  computers.  In  this  report,  we  are  referring  to  a  specific 
cloud  architecture  being  developed  by  the  IC:  a  cloud  of  clouds  called 


^  These  include  tools  to  accommodate  Maritime  Domain  Awareness  capability  needs. 

A  widget  is  an  application  or  interface  component  that  enables  a  user  to  perform  a  func¬ 
tion  or  access  a  service. 

This  open  architecture  could  be  enabled  in  a  number  of  ways  (e.g.,  use  of  an  enterprise 
service  bus,  development  of  an  application  integration  framework  that  facilitates  scalability 
with  respect  to  the  number  of  interfacing  applications).  This  would  alleviate  the  need  for 
pair-wise  interconnections  between  separate  tools. 
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Figure  5.4 

Alternative  3:  Cloud 
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the  Intelligence  Community  Government  Cloud  (ICGovCloud).^^ 
Compared  with  alternative  2,  which  relies  on  consolidation  that  is 
largely  physical,  alternative  3  is  virtual  consolidation  enabled  by  the 
cloud  computing  concept  and  its  associated  architecture. 

People.  As  in  the  baseline  scenario,  the  Navy  does  not  increase 
the  number  of  analysts  it  employs.  However,  alternatives  1,  2,  and  3 
employ  greater  usage  of  ashore  analysts  relative  to  the  baseline.  They 
also  assume  that  the  Navy  chooses  to  dynamically  manage  analyst 
workflow. 

Tools  and  technology.  Capability  is  provided  by  a  cloud  architec¬ 
ture  that  enables  development  of  web  services  and  widgets  that  bridge 
identified  gaps.  Once  again,  the  number  of  interfaces  required  is  equal 
to  or  less  than  the  number  of  interfaces  required  in  either  alternative  1 
or  the  baseline  scenario. 

Data  and  architecture.  Alternative  3  results  in  the  highest  level 
of  interoperability  relative  to  all  other  options,  scoring  a  “4”  on  the  LIST 


This  includes  “mini-clouds”  both  afloat  and  ashore  and  of  different  types  (e.g.,  a  data 
cloud,  a  utility  cloud,  a  storage  cloud)  (Greg  Shaffer,  “It’s  All  About  the  Data,”  presentation 
to  the  Armed  Forces  Communications  and  Electronics  Association,  August  21,  2012).  For 
further  details,  see  Porche  et  ah,  2013. 
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scale.  The  architecture  is  IC-driven  and  leverages  that  infrastructure 
and  those  tools  to  the  greatest  extent. 

The  Navy  is  currently  exploring  the  use  of  cloud  technology  to 
ingest,  store,  and  exploit  its  organic  (i.e.,  onboard)  sensor  data.  One 
vision  for  this  technology  is  that  all  organic  sensor  data  are  ingested 
and  then  forwarded,  on  demand,  to  shore-based  clouds.  This  would 
enable  distributed  alerting  and  analytics  initiated  by  strategic  and  tacti¬ 
cal  users.  The  goal  is  to  exponentially  increase  the  operational  relevance 
of  remotely  collected  sensor  data.  These  data  would  be  discoverable  and 
forwarded  on  a  per-request  basis. 


Advantages  and  Disadvantages  of  the  Alternatives 

Alternative  1  (applications)  is  designed  to  help  analysts  take  advan¬ 
tage  of  the  increased  variety  of  data  afforded  by  the  proliferation  of 
data  types  and  databases.  However,  adding  applications  to  worksta¬ 
tions  could  have  the  effect  of  complicating  an  analyst  s  job  rather  than 
streamlining  it.  Desktop  and  workflow  automation  tools  could  help 
mitigate  these  complications. 

Alternative  2  (consolidation)  results  in  the  physical  colocation  of 
diverse  data,  thereby  enabling  the  consolidation  of  tools.  Under  this 
alternative,  an  analyst  would  likely  need  to  master  fewer  interfaces 
than  in  alternative  1  or  the  baseline.  However,  a  certain  amount  of  raw 
data  would  still  be  passed  to  and  from  the  consolidation  point.  (The 
Army  used  this  approach  in  Afghanistan,  calling  it  the  Fusion  Brain }^) 

Alternative  3  (cloud)  results  in  the  virtual  collation  of  diverse 
data,  leveraging  IC  tools,  infrastructure,  and  data  to  a  greater  degree 
than  the  other  alternatives.  It  relies  on  a  data  strategy  that  includes  the 


A  small  Navy  program  known  as  “ISR  Lite”  demonstrated  that  it  is  possible  to  extend  a 
cloud  to  lower-echelon  “edge”  forces,  including  those  afloat  (Shaffer,  2012). 

See  Porche  et  ah,  2013. 
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use  of  metadata  and  the  adoption  of  a  common  metadata  catalog. 
Clouds  exist  afloat  and  ashore. 


Differences  Among  the  Baseline  and  the  Alternatives 

Table  5.2  describes  differences  among  the  baseline  and  the  alterna¬ 
tives  in  four  areas:  data-sharing  operational  concept,  security  domains, 
workflow,  and  data  flow.^^ 


Summary  of  the  Baseline  and  Alternatives 

Figure  5.5  summarizes  the  baseline  and  alternatives,  showing  effects 
on  the  four  dimensions  listed  at  the  beginning  of  this  chapter.  (See 
Table  A.l  for  additional  descriptions  along  other  dimensions.)  Our 
analysis  of  the  baseline  and  alternatives — including  their  relative  per¬ 
formance,  cost,  and  risk — follows  in  Chapter  Six. 


Metadata  are  data  about  data.  In  the  context  of  ISR,  metadata  associated  with  a  piece  of 
raw  data  might  include  such  information  as  what  type  of  data  it  is  (e.g.,  video,  audio),  where 
it  was  collected,  when  it  was  collected,  and  how  large  it  is.  The  Intelligence  Science  Board 
(2008)  recommends  that  metadata  tagging  of  sensor-collected  data  be  undertaken  and  that 
it  be  done  as  close  to  the  sensor  as  possible. 

RAND  identified  these  four  areas  of  importance  during  conversations  with  analysts, 
during  modeling,  and  during  the  study  described  in  Porche  et  ah,  2013. 
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Table  5.2 

Differences  Among  the  Baseline  and  the  Alternatives 


Data-Sharing 

Operational 

Alternative  Concept 

Security 

Domains 

Workflow 

Data  Flow 

Baseline  Stovepiped 

Multiple  security  Analysts  access 

Raw  and 

relational 

domains 

data  stored  in 

exploited 

databases  are 

persist.  Data 

unconnected 

data  flow  into 

accessed  locally 

are  exchanged 

databases  using 

sometimes 

and  remotely. 

across  them 

a  variety  of 

isolated,  site- 

using  guards 

applications 

specific  databases 

(e.g..  Radiant 

involving  many 

(i.e.,  stovepipes). 

Mercury). 

steps. 

Alternative  1:  Stovepiped 

Multiple  security  Automation 

Raw  and 

Applications  relational 

domains 

tools  help 

exploited 

databases  are 

persist.  Data 

streamline 

data  flow  into 

accessed  locally 

are  exchanged 

analyst 

sometimes 

and  remotely. 

across  them 

workflow. 

isolated,  site- 

using  guards 

reducing  the 

specific  databases 

(e.g.,  Radiant 

number  of  steps 

(i.e.,  stovepipes). 

Mercury). 

required. 

Alternative  2:  A  "fusion 

The  number 

Interoperability, 

Raw  and 

Consolidation  brain"  stores 

of  domains  is 

data 

exploited  data 

feeds  from 

reduced  to  two: 

consolidation. 

are  inserted  into 

various  data 

Secret  and  Top 

and  automation 

"brains"  located 

sources,  serving 

Secret. 

tools  help 

in  and  outside 

as  a  robust 

streamline 

the  continental 

information 

analyst 

United  States. 

clearinghouse  in 

workflow. 

a  small  number 

further  reducing 

of  relational 

the  number  of 

databases. 

steps  required. 

Alternative  3:  ICGovCIoud 

There  is  a  single 

,  Interoperability, 

Data  are  ingested 

Cloud  stores  metadata  consolidated 

automation 

and  tagged  at  the 

in  a  virtual  data 

classified 

tools,  and 

source.  Metadata 

analytic  cloud. 

security 

cloud-related 

are  shared  with 

domain. 

advantages 

local  and  IC 

result  in 

clouds.  Raw  data 

the  smallest 

are  shared  only 

number  of  steps 

upon  request. 

required. 

Figure  5.5 

Summary  of  the  Baseline  and  Alternatives 


Tools  and  Data  and 

Description  People  Technology  Data  Architecture 


Baseline 


tIht 


This  baseline 
relies  on  current 
plans. 


There  are  fewer  afloat 
analysts.  (DECREASE) 


Alternative!:  This  alternative 

Applications  adds  applications. 


There  are  fewer  afloat 
analysts,  but  there  is 
increased  reliance  on 
reachback  personnel. 

(REARRANGEMENT) 


Alternative  2: 
Consolidation 


ssg 

0  0 


This  alternative 
leverages  an  SOA 
(e.g.,  the  CANES 
program  of 
record). 


There  are  fewer  afloat 
analysts,  but  there  is 
increased  reliance  on 
reachback  personnel. 

(REARRANGEMENT) 


There  is  no  change.  There  is  no  change  in  the 
(NO  CHANGE)  approach  to  analyzing  data. 

(NO  CHANGE) 


The  Navy  adds 
applications,  including 
workflow-automation 
tools. 

(INCREASE 

APPLICATIONS) 


There  is  no  change  in  the 
approach  to  analyzing  data. 

(NO  CHANGE) 


The  Navy  adds  more- 
interoperable  services 
to  enhance  workflow 
automation. 

(INCREASE 

SERVICES) 


The  Navy  copies  the  Army's 
approach  of  depending  on 
an  information  clearinghouse 
(aka  "fusion  brain").  ^ 


Alternative  3:  This  alternative 


There  are  fewer  afloat 
analysts,  but  there  is 
increased  reliance  on 
reachback  personnel. 

(REARRANGEMENT) 


The  Navy  adds  more 
services  and  widgets. 

(INCREASE 

SERVICES) 


The  Navy  relies  on  the 
ICs  virtual  data  analytic 
cloud. 


SOURCES:  Screen  images  by  Eugene  Sergeev  and  Marcin  Gardychowski  via  Fotolia. 

RAND  RR31 5-5.5 


Demand  and 
Demand  Management 

There  is  no  change  in 
managing  personnel 
workflows  or  in  managing 
demand  for  data. 

(NO  CHANGE) 


The  Navy  manages  personnel 
workloads  dynamically.  Sensors 
are  cued  smartly.  ^ 


The  Navy  manages  personnel 
workloads  dynamically.  Sensors 
are  cued  smartly.  ^ 


The  Navy  manages  personnel 
workloads  dynamically.  Sensors 
are  cued  smartly.  ^ ^ 
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CHAPTER  SIX 


Analysis 


In  this  chapter,  we  evaluate  the  baseline  and  the  three  alternatives  in 
terms  of  their  relative  performance,  cost,  and  risk. 


Performance 

Using  modeling  and  simulation  tools  to  quantitatively  measure  perfor¬ 
mance  differences  among  the  alternatives,^  and  considering  multiple 
operational  missions  and  force  structures,  we  determined  the  following 
for  the  baseline  and  each  alternative: 

•  How  many  sensor  platforms  can  be  handled? 

•  What  volume  of  data  can  be  exchanged? 

•  How  much  electronic  imagery  can  be  analyzed  in  a  sufficiently 
timely  fashion? 

•  How  many  intelligence  types  can  be  fused? 

•  How  many  targets  can  be  identified  using  multiple  types  of  intel¬ 
ligence? 

One  useful  performance  metric  is  how  quickly  a  commander 
can  be  made  aware  of  the  targets  around  his  or  her  area  of  command. 


^  The  bulk  of  our  modeling  and  simulation  work  was  conducted  in  the  RAND-developed 
Processing,  Exploitation,  and  Dissemination  Architecture  and  Analysis  Tool  (PAAT).  This 
tool  has  broad  applicability  for  exploring  the  flow  of  intelligence  information  within  the 
context  of  a  mission.  One  of  PAAT’s  key  innovations  is  its  ability  to  simulate  intelligence 
specialist  workflows  at  a  level  that  represents  their  speciflc  tasks. 
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Figure  6.1  shows,  at  an  abstracted  level,  what  percentage  of  targets  are 
found  across  time,  given  data  of  a  single  intelligence  type.  The  baseline 
is  the  least  effective,  resulting  in  the  lowest  percentage  of  targets  found. 
Alternatives  1,  2,  and  3  outperform  the  baseline,  with  alternative  3 
(cloud)  resulting  in  the  greatest  number  of  targets  found  most  quickly. 

Figure  6.2  shows,  again  at  an  abstracted  level,  what  percentage 
of  targets  are  found  across  time,  given  data  of  multiple  intelligence 
types.  In  this  case,  analysts  are  fusing  data  from  two  or  more  different 
kinds  of  intelligence  sources — a  process  that,  as  we  explained  in  Chap¬ 
ter  Three,  improves  the  accuracy  or  “veracity”  of  the  commander  s  sit¬ 
uational  awareness.  Once  again,  alternatives  1,  2,  and  3  outperform 
the  baseline,  but  alternatives  2  and  3  offer  significant  improvements 
over  both  the  baseline  and  alternative  1.  Some  degree  of  colocation  of 
data  types,  whether  it  is  accomplished  physically  or  virtually,  appears 
to  significantly  enhance  performance  in  the  case  of  multi-intelligence 
analysis. 

Table  6.1  compares  the  overall  performance  of  the  baseline  and 
alternatives.^ 

Figure  6.1 

Commander's  Awareness  of  Targets,  One  Intelligence  Type 

(Abstracted) 


Cloud 

Consolidation 

Applications 

Baseline 


^  Results  for  all  of  the  metrics  are  detailed  in  Porche  et  ah,  2013. 
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Figure  6.2 

Commander's  Awareness  of  Targets,  Two  or  More  Intelligence 
Types  (Abstracted) 


Cloud 

Consolidation 


Applications 

Baseline 


Cost 

The  government  s  cost  analysis  of  the  baseline  and  alternatives  con¬ 
cluded  that  the  variance  in  lifecycle  cost  between  each  pair  of  options 
was  significant  but  not  large.^ 


Risk 

Our  assessment  of  the  risk  associated  with  the  baseline  and  each  alter¬ 
native  reflects  our  estimate  of  the  likelihood  of  an  adverse  event  and  the 
severity  of  the  consequences  should  that  event  occur.  We  considered 
technical  risk,"^  performance  risk,  and  schedule  risk  in  assessing  each 
option. 


^  U.S.  Department  of  the  Navy,  Center  for  Cost  Analysis,  “Distributed  Common  Ground 
System-Navy  (DCGS-N):  Increment  2  AoA  Cost  Estimate  Documentation,”  August  2012. 
Note  that  the  estimates  used  in  the  analysis  were  not  intended  to  be  “budget  quality.” 

^  Technical  risk  itself  has  at  least  three  components:  design  risk,  threat  risk,  and  require¬ 
ments  risk. 
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Table  6.1 

Comparing  the  Performance  of  the  Baseline  and  Alternatives 


Overall 

Alternative  Performance  Explanation 


Baseline 

Poor  across  all 
measures 

Performance  is  degraded  by  limited  use  of 
reachback,  an  information  architecture  that 
too  frequently  forwards  raw  data  through  the 
communications  networks,  and  insufficient 
workflow  automation. 

Alternative  1: 
Applications 

Better  relative  to 
the  baseline 

Performance  relative  to  the  baseline  is  improved 
through  dynamic  workload  management  and 
greater  workflow  automation. 

Alternative  2: 
Consolidation 

Good  across  all 
measures 

Performance  across  all  measures  is  good  due  to 
dynamic  workload  management  and  an  efficient 
information  architecture.  The  "brain"  serves  as 
an  information  clearinghouse  that  enables  the 
consolidation  of  tools  and  data.  This  further 
enables  workflow  efficiencies  and  affords  faster 
access  to  more  data  sources.  Analyst  ability  to 
fuse  multiple  intelligence  types  improves. 

Alternative  3: 
Cloud 

Good  across  all 
measures;  best 
across  some 

measures 

Performance  across  all  measures  is  good,  largely 
matching  the  performance  levels  of  alternative  2. 
However,  alternative  3  significantly  reduces  the 
strain  on  individual  communications  links  because 
its  effective  metadata  strategy  reduces  the 
need  to  share  raw  data  feeds.  This  alternative's 
distributed  cloud  approach  is  far  more  scalable, 
compared  to  other  options,  in  terms  of  data 
volume  and  sensor  platforms  that  can  be 
processed. 

Risk  analysis  often  involves  some  amount  of  subjectivity;  for 
example,  some  may  believe  that  cloud  alternatives  are  inherently  risky 
because  of,  for  example,  the  complexities  of  making  and  keeping  a 
cloud  secure.5  In  this  case,  conducting  an  assessment  of  overall  risk  was 
challenging  because  the  baseline  and  each  of  the  alternatives  scored 
very  differently  on  individual  measures  of  risk.  For  example,  the  base¬ 
line  involves  low  technical  risk  because  it  does  not  require  development 


^  Security  risks  associated  with  cloud  concepts  in  general  are  discussed  in  Neil  Robinson, 
Lorenzo  Valeri,  Jonathan  Cave,  Tony  G.  Thompson-Starkey,  Hans  Graux,  Sadie  Creese,  and 
Paul  Hopkins,  The  Cloud:  Understanding  the  Security,  Privacy  and  Trust  Challenges,  Santa 
Monica,  Calif.:  RAND  Corporation,  TR-933-EC,  2011. 
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of  new  technologies  and  systems.  On  the  other  hand,  the  risk  that  it 
will  not  meet  the  Navy’s  performance  needs  is  high.  Conversely,  alter¬ 
native  3  (cloud)  is  likely  to  meet  the  Navy’s  performance  needs,  but, 
because  it  involves  the  most  change  (in  terms  of  data  strategy,  database 
technology,  organizational  relationships,  etc.),  it  involves  greater  tech¬ 
nical  risk.^ 

The  baseline  and  each  of  the  three  alternatives  involve  risk,  and 
there  is  no  way  to  objectively  rank  their  overall  level  of  risk  relative  to 
one  another  without  weighting  individual  risk  categories.  In  our  opin¬ 
ion,  none  of  the  four  options  is  a  clear  “winner”  in  terms  of  being  sig¬ 
nificantly  less  risky  than  the  others. 


^  Porche  et  al.  (2012)  provide  a  detailed  discussion  of  risk  associated  with  specific  cloud 
architectures. 


CHAPTER  SEVEN 


Recommendations 


If  the  Navy  continues  to  field  new  and  additional  sensors  as  planned 
but  does  not  change  the  way  it  collects,  processes,  exploits,  and  dis¬ 
seminates  information,  it  will  reach  an  ISR  “tipping  point” — the  point 
at  which  intelligence  analysts  are  no  longer  able  to  complete  a  mini¬ 
mum  number  of  exploitation  tasks  within  given  time  constraints — as 
soon  as  2016.^  As  we  have  argued  in  previous  chapters,  a  solution  to  the 
Navy’s  big  data  challenge  must  involve  changes  along  four  dimensions: 
people,  tools  and  technology,  data  and  data  architectures,  and  demand 
and  demand  management.  This  means  that  the  Navy  needs 

•  more  than  just  new  tools;  rather,  it  needs  an  approach  to  integrate 
them  and  make  them  more  interoperable 

•  more  than  an  adjustment  in  the  number  of  analysts  at  each  site; 
rather,  it  needs  to  manage  analyst  workload  dynamically 

•  more  than  just  an  increase  in  the  number  of  distinct  intelligence 
sources  that  are  available;  rather,  it  needs  a  means  to  make  them 
easy  to  find.^ 


^  Brady  et  al.,  2012;  Porche  et  al.,  2012;  Porctie  et  al.,  2013.  Todays  budget  environment 
will  likely  affect  sensor  procurement  plans,  so  a  delay  in  the  tipping  point  is  possible.  None¬ 
theless,  it  looms. 

^  This  report  argues  that  no  single  program  of  record  can  completely  solve  the  data  flood 
problem.  A  materiel  solution  can  improve  today’s  existing  capabilities,  but,  to  meet  the  chal¬ 
lenges  of  the  future,  the  Navy  needs  new  ways  to  manage  people,  manage  demand,  accom¬ 
modate  new  tools  and  analytics,  and,  perhaps  most  importantly,  manage  data  through  effi¬ 
cient  data  strategies.  Addressing  just  a  single  item  on  this  list  will  be  insufficient. 
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Move  Forward  with  Alternative  3  (Cloud) 

We  recommend  that  the  Navy  move  forward  with  alternative  3  (cloud). 
It  offers  significant  potential  performance  improvements  despite  some 
technical  and  schedule  risk.  It  is  also  (arguably)  the  alternative  that  is 
most  amenable  to  future  changes  in  information  technology  tools  and 
applications. 

Specifically,  we  recommend  that  the  Navy  adopt  the  IC  s  cloud 
approach,  designing  the  next  generation  of  Navy  ISR  tools  and  systems 
to  work  with  the  National  Security  Agency  s  distributed  cloud  concept 
(i.e.,  ICGovCloud).  This  information  architecture  should  be  sufficient 
to  meet  the  growing  volumes  of  data  that  will  need  to  be  harvested 
and  thus  enable  viable  TCPED  operations  in  the  future.  Integrating 
and  leveraging  an  IC-developed  distributed  cloud  architecture  will  also 
better  enable  dynamic  reachback  for  analysis  and  thus  more-efficient 
use  of  manpower. 

Alternative  3  represents  a  fundamental  shift  in  how  data  are 
stored  and  shared  within  the  DoD  and  IC.  It  relies  on  a  data  strategy 
that  includes  the  use  of  metadata  and  the  adoption  of  a  common  meta¬ 
data  catalogue,  which  is  critical  to  achieving  performance  gains. ^ 

Bandwidth  limitations  and  other  constraints  on  an  information 
architecture  are  important  design  considerations.  RAND  modeling 
and  simulation  revealed  that  there  are  cloud  designs — coupled  with 
data  strategies — that  provide  the  best  approach.  We  conclude  that. 


^  According  to  Programs,  Management,  Analytics  &  Technologies  (2011), 

Metadata  is  the  most  effective  way  to  minimize  large  data  movement  and  to  inform 
naval  operators  of  the  availability  and  content  of  shared  data.  .  .  .  Although  meta¬ 
data  is  mandated  in  SECNAVINST  5000. 36A,  very  little  metadata  is  created  across 
the  .  .  .  [Department  of  the  Navy].  Part  of  the  problem  is  legacy  systems  do  not  automati¬ 
cally  tag  their  data  as  it  is  produced,  and  tagging  the  data  manually  is  labor  intensive. 
Tactical  users  are  already  time-constrained  and  often  do  not  appreciate  the  larger  enter¬ 
prise  usage  of  the  data  they  manage. 

The  Defense  Science  Board  Task  Force  on  Integrating  Sensor-Collected  Intelligence  spe¬ 
cifically  recommends  that  sensor-collected  data  be  tagged  with  “meta-data  as  close  to  the 
sensor  as  possible  using  metadata  that  includes,  at  a  minimum,  time,  location  and  sensor 
calibration”  (Intelligence  Science  Board,  2008,  p.  7). 
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with  an  efficient  data  strategy,  the  cloud  option  is  the  most  scalable  to 
increasing  volumes  of  data  from  ISR  sensors,  even  in  a  disconnected, 
interrupted,  and  low-bandwidth  environment. 


Extend  Aspects  and  Components  of  Alternative  3  to 
Other  Programs  and  Situations 

Many  aspects  and  components  of  alternative  3  can  and  should  be 
extended  to  other  programs  and  situations  in  the  Navy: 

•  Make  a  little  command  and  control  go  a  longer  way.  When  it 
comes  to  sharing  the  workload  among  analysts,  flexible  tasking 
and  retasking,  whether  conducted  regionally  or  globally,  make 
significant  productivity  gains  possible.  Retaining  relatively  more 
personnel  in  reachback  positions  is  desirable,  but  those  gains  are 
smaller  when  they  are  not  coupled  with  dynamic  management  of 
analyst  workload. 

•  Integrate  current  technology.  Integration  shortfalls  hurt  pro¬ 
ductivity.  Because  today  s  afloat  and  ashore  analysts  must  work  on 
multiple  networks  and  with  multiple  software  programs  and  data¬ 
bases,  their  workflow  is  often  disjointed  and  their  performance 
uneven.  Improving  integration  may  increase  accuracy  and  timeli¬ 
ness  in  the  development  of  situational  awareness. 

•  Make  use  of  new  information  architectures.  New  informa¬ 
tion  architectures  can  help  the  right  analyst  find  the  right  data  at 
the  right  time  and  thus  streamline  analyst  workflows.  The  Navy 
should  work  toward  decreasing  its  dependence  on  stovepiped 
applications  and  segregated  databases  and  networks. 

•  Automate  the  workflow  to  the  greatest  extent  possible.  Many 
of  the  rote  tasks  performed  by  afloat  analysts  could  be  automated 
through  desktop  software  tools.  Automating  repetitive  steps  and 
keystrokes  would  free  up  time  for  the  important  business  of 
acquiring  data,  exploiting  them,  and  using  the  resulting  knowl¬ 
edge  to  improve  situational  awareness.  It  would  also  improve  the 
speed  and  efficiency  of  the  process  of  fusing  exploited  products. 
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•  Tasking  sensors  smartly.  Inefficient  transmission  of  useless 
data — such  as  hours  of  video  of  the  open  ocean — serves  no  pur¬ 
pose.  Cueing  sensors  to  a  specific  target  would  prevent  the  collec¬ 
tion  and  transmission  of  unneeded  raw  data,  thus  lowering  bur¬ 
dens  on  bandwidth  and  on  analysts’  cognitive  reserves. 


Prepare  for  Culture  Change 

Alternative  3  involves  increased  reliance  on  reachback  personnel  and 
reachback  analytic  capability.  To  reap  the  full  benefits  of  the  cloud  solu¬ 
tion,  the  Navy  must  embrace  this  dependency.  However,  some  in  the 
Navy’s  deployed  community  are  predisposed  to  be  skeptical  of  relying 
on  analysis  from  the  rear.  Along  with  reasonable  concerns,  such  as  how 
this  approach  could  falter  in  communications-denied  environments, 
there  is  some  measure  of  long-standing  cultural  bias  against  reliance  on 
reachback  capability.  For  example,  the  Navy’s  own  historians  recount 
that,  as  the  use  of  wireless  radios  was  becoming  widespread  in  the  early 
part  of  the  20th  century,  “there  were  captains  and  even  admirals  who 
were  so  reactionary  in  their  views  and  so  jealous  of  their  prerogatives 
while  on  the  high  seas  that  they  resented  the  idea  of  receiving  orders 
by  wireless.  They  opposed  with  might  and  main  the  new  agency  of 
communications. In  addition  to  tackling  legitimate  concerns  associ¬ 
ated  with  increased  reliance  on  reachback,  the  Navy  must  be  prepared 
to  address  the  existing  bias  and  ease  the  cultural  shift  that  must  accom¬ 
pany  technological  change.  This  will  require  significant  effort. 


^  Gleason  L.  Archer,  as  quoted  in  Linwood  S.  Howeth,  History  of  Communications- 
Electronics  in  the  United  States  Navy,  United  States  Government  Printing  Office:  Washing¬ 
ton,  D.G.,  1963,  Ghapter  Six.  It  was  the  1912  sinking  of  the  Titanic  that  “highlighted  the 
value  of  radio  to  ocean  vessels”  (Thomas  H.  White,  “United  States  Early  Radio  History:  Sec¬ 
tion  Five,”  web  page,  undated). 
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Figure  A. 2 

Further  Illustration  of  the  Options 
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SOURCES:  Screen  images  by  Eugene  Sergeev  and  Marcin  Gardychowski  via  Fotolia. 
NOTE:  ONI  =  Office  of  Naval  Intelligence. 
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Table  A.1 

Additional  Descriptions  of  the  Baseline  and  Alternatives 


Design/ 

Development  Multi-Intelligence 

Alternative  Needed  Mean  LISI  Level  Sharing  Fusing  Anticipated  Effects 


Baseline 

No  new 
design  or 
development 
is  conducted. 
Design  and 
development 
are  limited 
to  planned 
sustainment 
and 

modernization 

activities. 

Level  1: 

Connected 

(interoperability 

in  a  peer- 

to-peer 

environment) 

There  are 

separate 

databases, 

separate 

applications, 

separate 

services,  and 

separate 

catalogs. 

Fusion  is 
accomplished 
"between  the 
ears"  of  individual 
analysts. 

No  change. 

Alternative  1; 

Design  and 

Level  2: 

There  are 

Fusion  is 

Some  workflow 

Applications 

development 

Functional 

separate 

accomplished  by 

automation  occurs  locally 

are  limited  to 

(interoperability  databases. 

individual  analysts 

across  the  workstation; 

integrating 

in  a  distributed 

separate 

but  enhanced  by 

capability  gaps  are 

tools  into  the 
Navy's  afloat 
(e.g.,  CANES) 
and  ashore 
environments. 

environment) 

applications, 
separate 
services,  and 
separate 
catalogs. 

specific  tools  that 
"integrate"  selected 
intelligence  types. 

addressed. 

Resulting 

Environment 


Physical 
connectivity 
is  established, 
allowing  bits  and 
bytes  of  data  to  be 
exchanged. 


Heterogeneous 
systems  exchanges 
are  enabled,  but 
separate  data  and 
applications  remain 
prevalent.  Some 
(minimal)  common 
functions  occur. 
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Table  A.1 — Continued 


Alternative 

Design/ 

Development 

Needed 

Mean  LISI  Level 

Sharing 

Multi-Intelligence 

Fusing 

Anticipated  Effects 

Resulting 

Environment 

Alternative  2: 

Design  and 

Level  3:  Domain 

There  are 

Interoperability 

Services  that  enable 

The  global 

Consolidation 

development 

(interoperability  shared 

enables  the 

the  achievement  of 

information 

are  required 

in  an 

databases. 

integration  of 

end-to-end  workflow 

environment 

to  make  tools 

integrated  Navy 

separate 

data  of  multiple 

automation  are  made 

is  highly 

interoperable 
and  to 
automate 
workflows 
afloat  and 
ashore 
within  the 
Navy's  SOA 
environment. 

environment) 

applications, 

separate 

services, 

and  shared 

catalogs 

(within  the 

Navy). 

intelligence  types 
for  tracked  entities 
in  a  more-automatic 
fashion,  allowing 
analysts  to  either 
quickly  fuse  multiple 
intelligence  types  or, 
in  some  cases,  have  it 
done  automatically. 

available  by  the  hosting 
environment.  The 
speed  and  accuracy 
of  multi-intelligence 
fusion  increase. 
Performance  gaps  are 
addressed.  Sophisticated 
collaboration, 
simultaneous 
interactions,  and  event- 
triggered  updates  occur. 

interoperable  and 
distributed,  "at  one 
with  the  human 
operator." 

Alternative  3: 

Design  and 

Level  4: 

There  are 

Fusion  of  multiple 

The  speed  and  accuracy 

The  cloud 

Cloud 

development 

Enterprise 

shared 

intelligence  types 

of  multi-intelligence 

architecture  is 

are  required 

(interoperability 

databases. 

benefits  from  cloud- 

fusion  occurs  through 

employed  both 

to  enable  the 

in  an  IC/DoD 

shared 

enabled  reachback; 

(1)  greater  utilization 

afloat  and  ashore. 

Navy  to  ingest 
and  process 
organic  data 
for  use  with 

IC  and  DoD 
data  in  a  cloud 
environment. 

environment) 

applications  efficiency  and 
and  widgets,  accuracy  increase  due 
shared  to  big  data  analytics; 

services,  and  ships  can  fuse 

and  shared  locally  collected  data 
indices  with  data  obtained 

(across  from  shore  clouds 

clouds).  through  cloud-based 

technology. 

of  organic  data  afloat  So-called  "mini- 

and  ashore;  (2)  more-  clouds"  are 

seamless  use  of  data  employed  afloat, 

across  multiple  security  The  resulting 

levels;  and  (3)  the  sharing  data  environment 
of  organic  afloat  sensor  facilitates  the 

data  to  the  wider  Defense  use  of  big  data 
Intelligence  Information  analytics  on  data  of 

Enterprise.  all  classifications. 
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In  the  U.S.  Navy,  there  is  a  growing  demand  for  intelligence,  surveillance,  and 
reconnaissance  (ISR)  data,  which  help  Navy  commanders  obtain  situational 
awareness  and  help  Navy  vessels  perform  a  host  of  mission-critical  tasks.  The 
amount  of  data  generated  by  ISR  sensors  has,  however,  become  overwhelming, 
and  Navy  analysts  are  struggling  to  keep  pace  with  this  data  flood.  Their 
challenges  include  extremely  slow  download  times,  workstations  cluttered  with 
applications,  and  stovepiped  databases  and  networks— challenges  that  are  only 
going  to  intensify  as  the  Navy  fields  new  and  additional  sensors  in  the  coming 
years.  Indeed,  if  the  Navy  does  not  change  the  way  it  collects,  processes, 
exploits,  and  disseminates  information,  it  will  reach  an  ISR  "tipping  point"— 
the  point  at  which  its  analysts  are  no  longer  able  to  complete  a  minimum  number 
of  exploitation  tasks  within  given  time  constraints— as  soon  as  2016. 


The  authors  explore  options  for  solving  the  Navy  s  "big  data"  challenge, 
considering  changes  across  four  dimensions:  people,  tools  and  technology, 
data  and  data  architectures,  and  demand  and  demand  management. 

They  recommend  that  the  Navy  pursue  a  cloud  solution— a  strategy 
similar  to  those  adopted  by  Google,  the  Intelligence 
Community,  and  other  large  organizations  ..  — - 

grappling  with  big  data's  challenges 
and  opportunities. 
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